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1.0 INTRODUCTION AND OVERVIEW 
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3.0 INTERNAL STRUCTURE, PHILOSOPHY, AND FLOW OF CONTROL. 


3.1 Introduction 

In this Section we will present the Internal operations of the RSX-11M 
Executive and the routines associated with It (drivers, and common 
service subroutines). Our exposition will have a tutorial slant. 
Section 5,0 contains a detailed description of the RSX- 11 M data 
structures. In this section we will introduce data structures on an 
as-needed basis, and discuss the detalleo contents of these structures 
only where needed to render our exposition meaningful. 


3,2 Interrupt Mechanisms 

RSX- 1 1 M is a priority driven, mul t 1 programml ng, real-time operating 
system, and, as with any such system, Its principal function Is the 
multiplexing of sharable resources among competing tasks. The 
multiplexing Itself Is made possible by the Interrupt system of the 
hardware which causes control to be taken away from user tasks and 
given to the Executive, It Is during this period of Interrupt control 
+ het the Executive makes Its decisions on granting use of shared 
resources, Underst andl ng the Interrupt mechanism Is fundamental to 
underst andl ng the Executive, and once understood, serves as a 
framework for describing the operation of Executive subsystems 
(drivers, loader, MCR, etc) and the system as a whole* 


3,2,1 Hardware Interrupt Mechanisms - Review R Overview 
The PDP-11 family of computers has two classes of Interrupts! 

1, Processor Traps, and 

2, External Interrupts, 

Processor traps ere not maskable*, that Is, when they occur the 
processor enters the trap sequence of pushing PS and PC onto the 
current stack, retrieving PS and PC from the orooer hardware trap 
vector, and, If no other Interrupts are pending, Initiating the 
processor at the location specified by the trap vector, A table of 
trap vectors start at location 4 and extend to location 774(8), 
Processor traps Include**! 


* Maskable means that the condition can be disabled by altering the 
priority of the processor, 

** See the PDP-11 Processor Handbook for a complete list. 



9PT Instruction! 


EMT Instruction! 

IOT Instruction! 

TRAP Instruction! 

11/40 Floating Point Exception Fault! 
Odd address! 

Power Fall# and 
1 1 1 egal Inst ruet 1 ons. 


External Interrupts are hardwired to one of the four bus reauest 
levels of the processor. These Interrupts are generally associated 
with I/O devices and are maskable. They can only cause an interrupt 
when the priority In the Processor Status Word C P S 5 is less than the 
priority of the Interrupting source. Thus# by setting the processor 
priority in a trap vector PS word to an appropriate level Interrupts 
equal to# or below that priority are locked out, 

Every device (Interrupt source) has an associated trap vector 1m the 
vector table located In lower memory. 

With this sketch of the hardware mechanism# we can examine the 
Interrupt processing In the Executive itself. 


3,2,2 Executive Interrupt Processing 

Let us assume that all the vectors In the trap' vector table have been 
properly Initialised so that when a processor trap or Interrupt 
occurs# an Executive routine will obtain control of the processor*. 

On a real memory PDP»tl**# only one stack exists# and this stack must 
be multiplexed to service the user tasks# the Executive# and the 
Executive Subsystems, 

The RSX« 1 1 M System supports n levels of user mul t 1 »programm1 ng and 250 
levels of user priority. The user establishes the priority of his 
task and the Executive dispatches user tasks based on the highest 


* Section xxx, xxx describes this Initialization, 

** See Section x,xxx for the details of mapped memory systems. 
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priority user task which Is ready to run. The System Task Directory 
(STD)# which Is composed of one 18-word STD Entry (Task Control Block 
(TCB)) for each user task In the system# and which Is ordered by 
priority# Is scanned to dispatch user tasks. 

Having only a single stack also Implies a single processor state. The 
Executive must simulate a two state system, A single word# the stack 
depth Indicator (SSTKDP), is used to control this simulation. 

When the stack depth Indicator Is equal to 1 the system Is running In 
the user state) when 1t # s zero or less# it Is In the system state. 
All stack multiplexing Is accomplished by testing the contents of this 
word. In passing# we should note that the priority set In the PS word 
for user tasks (both privileged and unprivileged) Is 0 # and for 
Executive routines# when running 1 nt e r rupt ab 1 e# Is either 0# 7 or the 
level at which the Interrupt was taken. It is a design goal to 
operate the Executive and Its associated routines non- 1 nt e r ruot ab 1 e 
for as short a duration as possible, we currently estimate the system 
never remains non- 1 nt e r rupt ab 1 e for more than twenty Instructions with 
the typical span of non-1 nterruotabl e codes being less than ten 
Instructions, Furthermore# the total non-1 nterruotabl e time will be 
less than 1/10 of IX of the total processor time. 

External Interrupts can occur within the system from either of the 
simulated states# that Is when the stack depth Indicator Is 1 (user 
state) or <»0 (system state). Processor traps# which Include the EMT 
Instruction used for Executive Directives# only occur In the user 
state# with the following exceptional 

TRAP Instruction 

Powerf al 1 

Describing the R S X - 1 1 M Interrupt mechanism Involves several 
Interrelated routines# and It may be necessary for the reader to make 
two passes over this section before the process becomes completely 
dear. To ease your passage# we introduce now a brief description of 
the basic routines Involved, 

The RSX-llM Interrupt machinery Involves the following routines or 
routine types! 

Interrupt processor (both external Interrupts and traps)) 

The Interrupt Save Routine (SINTSV)) 

The Directive Save Routine (SDIRSV)i 

The Interrupt Exit Routine (SINTXT)) 

The Directive Exit Routine (1DIRXT)# and 



PAGE 7 


The Fork Processors ( SFORK , SFORKP, SFORK 1) . 


Interrupt processors are entered directly and usually call SINTSV or 
SDIRSV for common save and state switching services? at the completion 
of these services# the interrupt routines are again given control to 
complete the interrupt service. The exit routines SINTXT and SDIRXT 
restore the state prior to switching to the system state# control the 
un«neeting of interrupts, and make checks on the state of the system 
(for example, is it necessary to redisoateh the processor). The Fork 
Processors linearise access to shared system data bases* The details 
of all these routines will emerge in the upcoming narrative* 


3*2*3 External Interrupt From The Task State (Stack Depth 
i ndi eator»l ) 

The vectors in lower memory contain a PC unique to each interrupting 
source# and a PS set with a priority of PR7* Hence# when an external 
interrupt occurs# the hardware pushes the current PS and PC onto the 
current stack (in this ease the users stack) and loads the new PC and 
PS (set at PR7) from the appropriate interrupt vector. The interrupt 
routine# then starts executing with interrupts locked out. Interrupt 
routines may# in fact# be executing in one of three states? 

1* At PR7 with interrupts locked out? 

2* At the priority of the interrupting source? thus, interrupt 
levels greater than the source are permitted, or 

3* At Fork level which is at PR0 , 

State 2 is discussed shortly'# state 3 will be deferred to Section 
3, 2*7*2 (Fork Processes)? for now, lets look at the PR7 state* 

By internal convention, processing in the PR7 state (Interrupt 
processing state l) is limited to 100us* If processing can be 
completed in this time# then the interrupt routine simply RTI's? the 
interrupt has been processed and dismissed with minimal overhead. 

If the interrupt routine requires additional processing time (but does 
not intend to alter a shared system data base) it calls the routine 
$ I NTS V (Interrupt Save), The priority at which the caller is to run 
immediately follows the call to SINTSV, 

Interrupt save uses the specified priority to set up the interrupt 
routine such that it is i nter rupt abl e by priorities higher than that 
of the interrupting source (interrupt processing state 2) and 
condi t i ona 1 1 y switches to system state if the processor is not already 
in system state. The SINTSV algorithm is? 
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^INTSVi Push R5 and R4 onto the current (user's) stack. 

Decrement stack deoth indicator 

Is the stack depth indicator 30? N©| go to 1 

Save the current (a task's in this case) stack Dointer 

Set up the system stack pointer (switch stacks) 

1, Load the new processor priority as specified by the caller 

Return to caller. 

Notes i 

The Stack Depth Indicator is zero only when the transition from the 
user state to the system state has occurred. The user state value of 
1 was selected to simplify the decrement, test, and branch which 
establishes whether a stack switch is mecessary, 

Pushing of R4 and R5 is done to free these registers for routines 
processing external interrupts. It is an internal programming 
convention that assumes these routines will not reouire more than two 
registers to accomplish their functions. If they do, they must save 
and restore any additional registers they use. 
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Example use of SINTSV* 


RKtl DISK CONTROLLER INTERRUPT SERVICE ROUTINE 

THIS ROUTINE IS ENTERED VIA THE VECTOR AT LOCATION 220 WHEN AN 
INTERRUPTING CONDITION IS DETECTED IN THE RK 1 1 CONTROLLER. THE 
ROUTINE IS ENTERED AT PRIORITY p R7 WITH ALL INTERRUPTS LOCKED OUT, 


SDKINTSJMOV PS, TEMP > S AVE VECTOR PS WORD 

CALL SINTSV, PR5 f I | SW ITCH STATES AND PRIORITY TO PR5 

) 

t CONTROL IS REGAINED AT THIS POINT IN SYSTEM STATE WITH A PRIORITY OF 
f PR5, REGISTERS RU AND R5 HAVE BEEN SAVED AND MAY BE FREELY USED. 

I 

MOV TEMP, R 4 mjRETRIEVE SAVED PS WORD 

BIC #177760, RU If f CLEAR ALL BUT CONTROLLER NUMBER 


etc. 

Implementation notei 

The CALL macro In the above example la a special form which la defined 
In the executive macro file RSXMC,MAC, This file must be concatenated 
with all assemblies using this form of CALL* The eode generated from 
the macro expansion 1st 

JSR R5, SINTSV 

.WORD *C<Pr1 orl ty>&pR7 


3,2,4 External Interrupts From The System State (Stack Depth 
Indicator <«0) 

The code on this Interrupt path Is Identical to that discussed In 
Section 3,2.3* However, It Is not necessary to switch states when 
SINTSV Is called. The current stack Is the system stack, and the test 
on the value of the stack depth Indicator will cause the saving of SP 


a We Intend to make extensive use of examples throughout this manual 
and will repeat coding sequences where necessary to relieve the 
reader from continually paging to find another related example. 
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and the switching of staeks to be bypassed. After saving Pa and R5 on 
the system stack, a return to the interrupt routine is executed. 
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3,2,5 Processor Traps From The Task State (Staek Depth Ind1eator»l) 

When a processor trap occurs from the task state, the hardware pushes 
PS# PC# and initiates the routine specified In the associated hardware 
trap vector. If the trap was an Executive directive (E M T 377)# the 
DP8 (Directive Parameter Block) or Its address was pushed onto the 
user's stack prior to the Issuance of the EMT, The trap routine, 
running at PR7 Immediately calls the routine $ D I R S V (Directive vSave) 
which has the following algorithm: 

SDIRSV: Push R5 and R4 onto current (user's) stack 

Decrement Stack depth Indicator 
Is the stack depth Indicator s0? No# go to l. 

Save current (user's) stack pointer 

Set up system stack pointer (switch stacks) 

1, Push R3#R2#R1#R0 onto current (system) stack 

Load new processor priority as specified by the caller 
Return to caller* 


Notest 

The depth Indicator check Is made to Improve crash analysis! no other 
decisions are made In SDIRSV .since all processor traps# with two 
exceptions# occur from the task state. The exceptions are handled on 
exit. All registers are saved! the need for only two registers# R5 
and R4 Is assumed only for routines processing external Interrupts, 
As with SINTSV the priority at which the caller expects to run 
Immediately follows the call. All processor trap routines# however# 
run at level 0, 

Only one processor trap can be oueued for processing in the system at 
any point In time (Ignore# for the moment# the two exceptions we have 
noted), Slnee the processor trap occurred In the In task state, 
entrance to the Executive occurs only when the Executive is Idle, 
While In the System State, only external Interrupts can occur. If 
processor traps occur# then either they are valid exceptions, or the 
system Itself has faulted and will shut down. 

Once a valid processor trap Is pending, it will be processed to 
completion before any other system routine Is given access to any 
shared system data base. We will see how this strict seouent 1 a 1 1 1 v Is 
effected when we discuss the two exit routines and the fork 
processors. 
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Example use of SDIRSV 


EMT TRAP PROCESSING ROUTINE 

THIS ROUTINE IS ENTERED VIA THE VECTOR AT LOCATION 30 WHEN *N EMT 
INSTRUCTION IS EXECUTED, THE ROUTINE IS ENTERED AT PRIORITY PR7 
WITH ALL INTERRUPTS LOCKED OUT, 


SEMTRP I I CALL 
TST 
BEQ 
CRASH 

10 $! 


SDIRSV, PR0 
SSTKDP 
10 $ 


9 f f SWITCH STATES AND PRIORITY TO PR0 
lEMT EXECUTED FROM SYSTEM STATE? 
f IF EQ NO 
j CRASH SYSTEM 


etc. 


Implementation notei 

The CALL macro In the above example Is a special form which Is defined 
in the executive macro file RSXMC,MAC, This file must be concatenated 
with all assemblies using this form of CALL, The code generated from 
the macro expansion Isi 

JSR R5#$DIRSV 
# wORD *C<P r 1 or 1 ty>&PR7 


3,2,6 Processor Traps From The System State (Stack Level <a0) 

Only two processor traps are valid from the system state! The trap 
Instruction and powerfall. If any other processor trap occurs while 
In the system state, the system's operation Is aborted. 


3,2,6, t Processing For Trap Instructions Which Occur In The System 
State 

The trap Instruction Is used within the Executive as a core saving 
technique In returning status following the processing of an Executive 
Directive, The EMT 377, which Is the processor trap used to Initiate 
directives, causes entry Into the Directive Dispatcher (SEMTRP) which 
In turn calls SDIRSV, on return from SDIRSV, but before calling the 
directive processing routine (and entry to the proper routine Is via a 
CALL)# the Directive Dispatcher pushes a value of *1 onto the system 
stack, and clears the C bit In the PS word stored on the users stackj 
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then it calls the proper directive processing routine to effect the 
directive# Figure 3,1 shows the state of the user and system stacks 
for both the unmapped and mapped systems at the time entry is made to 
the directive processing routine. 
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FIGURE 3-1 


The Directive processing routine now carries out Its function, and In 
so doing Is free to alter any shared system data base, since no other 
routine will gain access to a shared data base until the directive 
processing routine Is completed. This arrangement of the stack and 
Interface between the Directive Dispatcher ana the Directive 
Processors has two advantages! 

1, The normal return for all but a few directives Is a +1 status 
and carry clean. This means the directive routines can 
return to the dispatcher with an RTS; thus the return oath Is 
one word rather than two If a JMP were employed; this scheme 
probably saves 100 words In the RSX-HM Executive, 

2, Internal Executive routines can call the directive processing 
routines without using an EMT, 

If a directive processing routine needs to return a status' other than 
♦1# and have carry clear, the routine simply replaces the +1 on the 
stack with the value It Intends to return and then executes an RTS, 

Now we come to the use of the trap Instruction within the Executive, 
If a directive processing routine needs to return a status other than 
•Hi and, In addition have carry set, or cleared, based on the status 
value returned, then It uses the trap Instruction with the value of 
status to be returned In the low order byte of the Instruction, When 
the trap processing routine Is entered, It Immediately checks for 
stack depth»0, and If 0, proceeds to reset the stack for correct 
exiting from a directive processing routine. The low order byte of 
the trap Instruction Itself overlays the +1 status currently on the 
stack; this value Is tested and, If minus, carry Is set In the user PS 
word, If plus, carry Is left cleared. Then the exiting code of the 
Directive Dispatcher Is entered Just as If the directive processing 
routine had executed an RTS, 

If the Initial test for a stack depth Indicator of 0 falls# then the 
trap processing routine calls SDIRSV, This call is logically 
Incorrect If the stack depth Indicator was less than zero. This 
programming error Is recognized on exit. On return from $DIRSV, the 
trap processing routine checks the stack depth Indicator, and If It Is 
not sero, the system Is shut down. 

Note that directives are legitimate only from the task state (stack 
depth Indicator^) so that during directive processing, the stack 
depth Indicator Is always 0* Interrupts that occur In system state 
disappear from the staek before the directive processing seauence 
resumes following an Interrupt, Hence, even though the stack can grow 
while a directive processor Is In control, this growth Is transparent 
to the directive processor. Stating It from a different perspective, 
interrupts are Permitted but the directive processor In control Is 
unaware of them. 
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Directive processing routines thus Have three methods of returning 
st atus I 

1, For the normal return carry dear and status eaual to +1# use 
an RTS. 

2, For carry clear and status other than +1, overlay the +1 
status on the stack with the desired status value (status 
value Is at 2 C S P D")# and RTS. 

3, For carry clear or set# and status of one byte# use the trap 
Instruction, This requires more overhead than 1 and 2 above 
but saves core# and# of course Is the reaulred return 
mechanism If carry Is to be set. 

Together# these return mechanisms from directive processing routines 
save between 200 and 300 words In the RSX-ilM Executive as compared to 
returning via Jump 1 nst ruct 1 ons. 


3, 2, 6, 2 Powerfall Processing 

Whan a power failure occurs# the power failure trap processing routine 
is entered. This routine saves the state of the system# sets up a new 
power failure trap»vector PC for use when power Is restored, then 
HALTS. 
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On restoration of power# the state of the system at the time the 
failure occurred is restored# a flag is set by software indicating 
that a power failure has occurred# the reschedule pointer* is set to 
the null task# and the clock is re-enabled. Then# the restoration 
code issues an RTI# which results in the resumption of the processing 
that was in progress when the cower failure occurred. The 9oeei*ic 
processing to reflect the occurrence o* a power failure will not occur 
until either Directive Exit is entered or the clock interrupts. In 
any event, this processing is part of Directive Exit and will be 
discussed under Directive Exit, 

Note that power failure processing is not asynchronous. As much as 
1/60 of a second could elaose following restoration before the cower 
failure is acted upon. 

The records and logic needed to provide asynchronous processing are 
simply too large for a system with RSX-llM's core objectives. Our 
assumption is that asynchronous power»f ai 1 ure processing is not 
consistent with RSX-llM # s objectives or markets. 


3, 2,6, 3 Aborting The System 

When a condition is detected that indicates the system should be shut 
down (crashed in an orderly manner)# the detecting routine issues an 
I0T, The I OT processing routine# as usual# calls Directive Save# and 
on return checks for a stack depth equal to zero. If equal# normal 
SST processing is entered. If not equal to zero# the routine $CRA$H 
is entered. Crash displays# on the device whose CSR address is 
CSSRSH# an appropriate printout which is detailed in Appendix I, 
After completing the printout# it Jumps to a routine called SPANIC# 
which optionally prints out an edit of selected memory locations. In 
the minimum system both SCRASH and SPANIC are condi t i onal i zed out# and 
a system crash simply results in a processor halt at location 560(8), 


3,2,7 Processing Within Interrupt Routines 

In Section 3,2,2 we examined interrupt entry into tl*e RSX-llM 
Executive, In this section we detail the events which take place 
following interrupt entry up to the point where the Executive is ready 
to return control to the task state. 

Once the Executive is entered via an interrupt (regardless of the 
state its in whan the interrupt occurs) it will not again return to 


The reschedule pointer will v be Covered when we discuss task 
switching. 
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the task state until all system related processing for that interrupt 
has been completed* From another point of view# the task state is 
never in control unless the Executive Has not h ! ng- to-do (is idle). 

While in the task state a single Interrupt causes transfer into the 
system state where the system remains until the interrupt is 
processed. But while in the system state, repeated interrupts can 
occur. This implies a fixed interrupt deDth of one for the task stack 
(requiring a task to provide a stack of at least four words in an 
unmapped system), and implies a variable interrupt depth for the 
system stack. 

If interrupts can occur In the system state, then a mechanism is 
required to prevent unwanted recursion and improper data base 
modification. In RSX-11M both of these logical difficulties are 
resolved by strictly linearizing interrupt processing and access to 
internal data bases. The mechanisms employed to accomplish this 
1 i near I zat i on are the system stack, fork processes, and the associated 
fork list, 


3,2,7,1 Queuing Interrupts On The System Stack 

In the system state the goal is to operate i nter rupt i bl e as much of 
ihe time as possible. Three conditions exist when the system itself 
runs non-i nterruptabl et 

1, The most recent Interrupt is being processed at level PR7 and 
the interrupt routine has not yet returned to an 
i nterrupt i bl e state, 

2, The interrupt routine has drooped from level PR7 to the level 
at which the interrupt occurred. Priority levels, eaual to 
or less than the priority of the interrupting source are 
locked out, 

3, The system Is updating a critical list whose consistency can 
only be maintained by a non-! nterruotabl e instruction 
sequence. There are two such lists, ahd we will discuss them 
short 1 y. 

In Sections 3,2,3 and 3,2,4 we examined the code seauence for 
processing external interrupts and processor traos, as well as the 
stack additions that occurred during their processing. Interrupt 
stacking in the system state will occur based principally on hardware 
interrupt levels. Thus if a level PR4 interrupt is being processed, 
then a level PR5, PR6, or PR7 interrupt can potentially interrupt this 
processing and cause context to be stacked and control given to the 
higher level interrupt routine. 
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3, 2, 7, 2 Fork Processing And The Fork List 

Once an Interrupt routine passes from a non- 1 nt e r ruot 1 b 1 e to an 
1 n t e r rupt 1 b 1 e state via a call to SINTSV, processing Is at the same 
level as the priority of the Interrupting source. Along any given 
interrupt path however, more processing Is often reaulred than the 
goal of mlnimun non*1 nterupt 1 bl e code sequences In the Executive 
permits! along this path the allowable maximum non*1 nterrypt 1 bl e 
processing time Is 500us, Thus# a scheme Is required to split 
Interrupt processing routines further# such that part of their 
execution runs 1 nt e r ruot 1 b 1 e to any Interrupting source. The 
mechanism for achieving this split Is called fork processing. Fork Is 
an Internal subroutine with three entry points! fork linearizes 
accesses to system data bases# thus eliminating unwanted recursl on 'and 
mu 1 1 to 1 e-updates of these data bases. An associated list# the Fork 
List# which Is processed FIFO# Is used as the linearizing structure, 

Interrupt routines are required to adhere to the following Internal 
convent Ions* 

1, Use of any registers exceot R4 end R5 requires that these 
registers be saved and restored, 

2, Non«1 nterrupt 1 bl e processing must not exceed twenty 
1 nst ruct 1 ons, 

3, All modifications to system data bases must be done via a 
fork process. The first two requirements are 
st ral ght f orward# so lets turn our discussion to Fork, 

Along an Interrupt path# control can be taken from a routine only due 
to a higher priority Interrupt pending In the hardware. As discussed 
previously# these Interrupts are keot track of on the system stack. 
When an Interrupt routine needs to transfer from a nenl nterruot 1 bl e 
(Including partial non-1 nterrupt 1 bl 1 1 tv) to an 1 nter rupt 1 bl e state# or 
modify a system data base, It must call Fork, Fork, however# cannot 
be called directly from an Interrupt routine! It must first switch to 
system state by calling Interrupt Save and then call fork. 

Fork has three entry points depending on the size of the fork block 
being provided by the caller for context storage, 

SFORK requires a 4-word fork block which contains* 

A forward link In the fork list 

PC of the call er 

Saved R4 


Saved R5 
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iFQRK Is for I/O drivers and the fork orocessor assumes R S Is loaded 
with the unit control block (UCB) address, 

SF0RK1 reauires a 3-word fork block containing! 

A forward link In the fork list 

PC of the caller 

Saved R5 

SFORKfl reauires a 2-word fork block containing! 

A forward link In the fork list 
PC of the call er 
SFORK when cal led! 

Stores the return PC# P5 and R4* Into the fork block. Appends 
the supplied fork block to the fork list# and Jumps to Interrupt 
Exit, 

By vlrture of calling fork# the routine Is now 1 nter ruot 1 bl e and Its 
access to system data bases Is strictly linear. The Interrupt 
(Drocesslng routine Is now In state 3, (Refer to Section 3,2,3 for a 
discussion of states t and 2), The Fork List Is a list of system 
routines waiting to complete their processing# In particular# waiting 
to access a shared system data base. 

When the Fork routine# after placing the fork block In the fork list# 
Jumps to SINTXT the stack Items for the Interrupt routine are removed 
from the stack. In effect the fork list Is a secondary Interrupt 
queue (stack) whose members are processed FIFO# and obtain processing 
time only If the system stack Is empty. 

Note that the context saved for a caller of SFORK depends on which 
entry point Is called# and the context saved Is all that Is needed to 
restart routines on the fork list. 


1 ) ★ R5 and R4 will or will not be stored depending on which variant of 
Fork Is call ed. 
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Example call to $ F 0 R K 
? ♦ 

I RK 1 1 DISK CONTROLLER INTERUPT SERVICE ROUTINE 
i 

I THIS ROUTINE IS ENTERED VIA the VECTOR AT LOCATION 220 WHEN an 
| INTERRUPTING CONDITION IS DETECTED IN THE RK 1 1 CONTROLLER, THE 
I ROUTINE IS ENTERED AT PRIORITY PR 7 WITH ALL INTERRUPTS LOCKED OUT 


SDK I NT ! t MOV 
CALL 
MOV 
BIC 
ASL 
MOV 
TST0 
BEG 
• 

drive reset processing code 


50S i CALL SFORK > ? f CREATE A FORK PROCESS 


5 CONTROL IS REGAINED AT THIS POINT WITH ALL INTERRUPTS ALLOWED, 


PS, TEMP 
$ I NTS V # PR5 
TEMP,RU 
#177760, R4 
R4 

CNTBLCR4) ,R5 

RTTBL+1CR4) 

50S 


?SAVE VECTOR PS WORD 

I SW ITCH STATES AND PRIORITY TO PR5 

^RETRIEVE SAVED PS WORD 

f CLEAR ALL BUT CONTROLLER NUMBER 

? CONVERT TO WORD INDEX 

^RETRIEVE ADDRESS OF UCB 

jDRIVE RESET IN PROGRESS? 

|IF EQ NO 


3,2,8 Exiting The System State 

In Section 3,2,2 • 3,2, 7,2 we covered the Executive's processing of 
interrupts, and the methods employed to linearize their processing so 
as to minimize the non»i nterruot i bl e tine scent in the system state. 
In several places we referenced two routines SINTXT (Interrupt Exit) 
and SDIRXT (Directive Exit), These routines result in the sequential 
removal of all items on the system stack, then all items on the fork 
list. It is these two routines to which we now turn. 

The Executive's strategic objective is to return to equilibrium (the 
idle state) as fast and as efficiently as possible? its tactics to 
achieve equilibrium is to is to service all routines on the svstem 
stack first# These routines are usually running at some level of 
non« i nt er rupt i b i 1 i t y , when the system stack is cleared of pending 
requests, the Executive then services the pending requests on the fork 
list. When both the fork list and system stack are empty, the 
Executive will either return to the task state or if no task is 
active, drop into the Null Task, 

tINTXT is transferred to by external interrupt processing routines 
that are running on the system stack at the priority of the 
interrupting source (state 2 for those interrupt processing routines). 
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^DIRXT Has the task of servicing the fork Hst and# when the Executive 
has no more work to do# restoring the task state* SDIRXT Is entered 
by trap routines# fork routines# and by SINTXT, 


3,2, 8,1 Interrupt Exit (SINTXT) 

The $ I NT X T algorithm Is as follows! 

SINTXT! lock out Interrupts 

Is stack depth 1nd1cator»0? No# 9o to 1, 

Is fork list empty. Yes# go to 1, 

Allow 1 nter ruot s. 

Store R3#R2#R1#R3 on the current (system In this case) stack 
Jump to SDIRXT (Directive Exit), 

1, Increment stack depth Indicator, 

Restore R4 and R5 from current stack and RTI, 

Notes! 

Interrupts must be locked out to insure a consistent check of the 
stack depth indicator and the contents of the fork list. The same 
type of lockout occurs In Directive Exit, There are two 
non-1 nterruPt Ibl e code spans used to check and update the fork list 
mentioned in Section 3,2,7,!,# one in SFORK# and one in SDIRXT, The 
saving of R3 thru R0 Is prepatory to the Jump to SDIRXT which expects 
these registers on the stack. Note that the oath through the 
Executive which find both the fork list emotv and the stack depth 
Indicator equal to 0 Is fairly common. As can be seen# this Is the 
minimum overhead path. 


3, 2, 8,2 D 1 recti ve Exit 

The SDIRXT algorithm Is as follows! 

SDIRXT! Lock out Interrupts, 

Is the fork list empty? Yes# ao to 1, 
Update Fork list pointers. 


Allow 1 nterrupt s. 
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Restore Fork context. 

Call routine whose fork context was restored. 

Go to SDIRXT. 

1, Is rescheduling required (SRQSCH notsGU? No* go to 2, 

Allow i nt er rupt s. 

Clear SRQSCH, 

Save context of current task. 

Locate a ready-to-run task. 

Restore context of new task. 

Go to SDIRXT , 

2, Is the power failure flag set? No# go to 3, 

Allow i nter rupt s 

Call power failure processing. 

Go to SDIRXT 

3, Restore task stack pointer. 

Increment stack depth indicator. 

Restore R4 and R5 from user stack and RTI, 

Notes I 

SDIRXT calls both waiting fork processes and the powerfail routine. 
These routines terminate via a RTS instruction. On return SDIRXT 
again cycles looking for work. 

The tas 1 * reschedule pointer SRQSCH controls the redi soatch i ng of the 
processor. It points to the location in the STD list where SDIRXT 
should begin its scan for a task ready to use the processor, 

SRQSCH is set when a change of state has oceured in the system that 
night cause a task other than the one currently in control to obtain 
processor time. Examples are I/O done# clock oueue runout, or a task 
doing an EXIT, The word is reset by SDIRXT just prior to its 
dispatching a new task. 
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3,2*9 Interrupt Processing Summary 

Seven routines or groups of routines not only comprise the interruot 
system but can be said to practically comprise the entire Executive 
itself. 

External Interrupt Routines 

Trap Routines 

Interrupt Save 

Directive Save 

Forx and Fork Processes 

Interrupt Exit 

Directive Exit 

External interrupts cause traps to external interrupt processing 
routines which run in one of three states) 

1, Non- i nter rupt i pi e at PR7, 

They run here when initially entered, 

2, Inter rupt i bl e by priorities higher than the interrupting 

source. 

Both states l and 2 are linearized being queued and dequeued 
from the system stack, 

3, Fully i nterruot i bl e as fork processes. 

Trap routines *of which only one may occupy the system stack during 
any given passage through the Executive* operate at priority level 
zero* need never call Fork* and operate entirely from the system 

stack. 

Interrupt save is called by external interrupt routines when they make 
a transition from state 1 to state 2, 

Directive save is called by trap routines. 

Fork creates a fork process for external interruot routines. 

Interrupt Exit unstacks waiting routines executing from the system 
stack, and when the system stack is empty drops into Directive Exit, 

Directive Exit has the Job of giving control to waiting fork 
processes, processing power failure, and redi soatch i ng the processor. 
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The Executive structure Has an implied sequentiality which obviates 
the need for any explicit sync h ron i z i ng mechanisms. System routines 
which follow the internal conventions of the Executive never need 
concern themselves with mul t i ol e-uDdate of shared system data bases. 
In tending toward the idle state the Executive gives priority to 
routines on tne system stack, then to fork processes. 
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3,3 I/O Processing 


3,3,1 Goals 

The I/O interface is 100% compatible with RSX-iiD, Within the 
requirement of compatibility# three goals guided the design? 

1, The total memory for I/O processing (data structures plus 
drivers) must be reduced by 50% vs RSX-ltD, 

2, The I/O data structures should have substantial flexibility 
for adding future devices# or for altering the service 
discipline of existing devices, 

3, Throughout should equal or exceed RSX-llD's, 


3,3,2 I/O Philosophy and Functional Overview Of Its Implementation 

To meet its stated goals# the RSX-ilM I/O system attempts to 
centralize common functions# thus eliminating the repetitive 
appearance of code# which is almost identical in form and function# 
^om appearing in each and every driver in the system. To achieve 
this# a substantial effort has been expended in the design of 
RSX»llM # s I/O data structures which are used to drive the centralized 
routines. The effect is to substantially reduce the size of 
individual I/O drivers? an RSX- 11 M driver is typically one-fourth as 
large as its RSX-110 counterpart. Of course# the centralized code# 
and an increase in the size of RSX-llM's data structures compared to 
RSX-l!D # s reduces our effective size reduction. But# on the balance# 
we have substantially reduced the size of our total I/O processing 
core requirements while at the same time produced a more 
understandable# mai nt ai nabl e# and enhanceable I/O system (obviously# 
our subjective Judgement), 

The user interface to the RSX-11M I/O system consists of logical unit 
numbers (LUNs) and a single active I/O directive QUEUE I/O, (The 
directives ASSIGN LUN, GET LUN INFO# etc, do not initiate I/O 
t ransf ers) , 

In RSX-11M all the preliminary processing antecedent to actually 
queuing an I/O request is performed by the GIO directive processing 
eode which is driven from the I/O data structures? this code calls 
ancillary routines for centralized services, when a driver finally 
receives an I/O order# it has very little to do other than set up the 
status registers and issue the order. 

Termination processing is equally modular and centralized. The driver 
is entered# performs some cleanup operations# and cells centralized 
routines for obtaining pending I/O orders# performing AST processing# 
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etc* The driver is only concerned with the most intimate and specific 
details of the actual hardware interface in respect to the execution 
and completion of I/O transfers. Using tMs cent ral i zat i on 
philosophy, RSX-llM keeps both driver size and non- i nt e r ruot i b 1 e 
processing time small. 


3,3,3 RSX-UM I/O Data Structures 

The static* I/O data structures consists of three distinct entities! 

1, A Device Control Block (OCB)i 

2, A Unit Control Block (UCB), and 

3, A Status Control Block (SC8), 

Although each serves a soecific function, and the components of each, 
in general# reflect these functions, the coherence achieved by a 
strict set of rules for determining into which data structure a 
specific unit of information would be placed was ultimately sacrificed 
to core savings and code efficiency. The exceptions, however, are 
few, and the functional purpose of each data structure is reflected by 
the units of information which compose them. 


3,3,3, 1 The Device Control Block (DCB) 

One device control block exists for each device type attached to the 
system. Its function is to describe the static character i st i cs of 
both the controller and the units attached to the controller. All the 
DCB's in the system are singly linked. The DCB contains such 
information asi 

The device mnemonic CTwo ASCII characters) 

The lowest and highest Unit Numbers on the respective Controller 

The address of the first uCB 

The Length of Each UCB 

The next DCB Pointer 

The Legal Function Mask 


* Static in the sense that they are established at SYSGEN and only 
another SYSGEN can expand or contract the number of I/O units served 
by the structures. 
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The Control Function Mask 
The No»0p # d Function Mask 
The File Function Mask 

The Pointer to the Driver Dispatch Table 

All these information units are static and are used principally by the 
QUEUE I/O directive processing code to prepare a Queue I/O reauest for 
a device driver. The details of QUEUE I/O Processing are in Section 

3.3.5, 


3. 3, 3. 2 The Unit Control Block CUCB), 

One unit control block exists for each physical device unit attached 
to the system. Many of its information units are static, though it 
does contain a few dynamic parameters. For example the redirect 
pointer which reflects the result of a Redirect mcr command. 

The UCB contains device unit specific data, such as unit status, 
physical unit number, and unit characteri st i cs. 


3.3,3.3 The Status Control Block (SCB), 

One status control block exists for each device controller in the 
system. This is true even if the controller handles more than one 
device unit (like the RK Controller), Line multiplexers such as the 
DHli and DJ11 are considered to have a controller per line since all 
lines may transfer in parallel. 

Most information in the SCB is dynamic. It contains the following 
information about the currently active unit! 

The Interrupt Vector Address 

The Controller Bus Reauest Priority 

Timeout Counts (Initial and Current) 

The Address of the Control Status Register 

The Address of the Current I/O Packet 

Storage For A Fork Block 

The I/O Queue Listhead 
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The Controller Status (Busy/Idle) 

The Cont ro 1 1 er Index 

As can be seen, the SCB is quite dynamic# making it possible to 
maintain control of the current I/O In progress on the controller. 
The presence of the fork block storage In the SCB Implies I/O 
linearity for the processing at fork level on a given controller. We 
have here a specific example of how multiple updates and recursion are 
controlled. The driver for a specific device type never concerns 
Itself with unwanted recursion or multiple updates. Once a driver Is 
In a fork level process# further I/O processing# which may involve 
updating a shared data base# Is automatically locked out by the 
structure of the system Itself, 


3,3,4 Some Sample I/O Structures 

Figure 3-2 shows the data structure that would result for three 
terminals each Interfaced via a Dili asynchronous line Interface, The 
structure requires three UCBs and three SCBs since the activity on all 
three units can proceed In parallel. In Figure 3-3 the Internal data 
structure for an RK disk controller with three units Is depicted; 
note that only one SCB exists because only one of the three units may 
be active at any time. 
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3*3,5 Queue I/O Directive Flow 

The Queue I/O directive reaulres the Issuer to construct a twelve word 
directive parameter block as shown in Figure 3-4, 
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Figure 3*4 


The parameters have the following i nterpretat i on. 

Length (reouired)t 

The length of 0 p B, For 010 always equal to twelve words. 
DIC ( reoui red) I 

Directive Identification Code, For QIO, the value is a 1, 
Function Code (reauired)i 

The eode of the reguested I/O function CO thru 31,). 

Modi fieri 

Device dependent modifier bits. 

Reserved! 

Reserved bvte and must not be used. 


LUN ( reoui red) | 
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Logical Unit Number, 

P r 1 o r 1 t y l 

Request priority. Ignored by RSX-11M, but space must be 
allocated for RSX»110 compatibility, 

EFN ( opt ionaUl 

Event f 1 ag number , 

I/O Status Block Address (optional)! 

This word contains a pointer to the I/O status block which Is a 
4»byte device dependent I/O completion data packet formatted as* 

Byte 0 

I/O status byte 
Byte 1 

Augmented data supplied by the driver 
Bytes 2 and 3 

The contents of these bytes depend on the value of byte 0, 
If byte 0*1 then these bytes contain the processed byte 
count. If not=l# then the contents are device dependent, 

AST Address (optional)! 

Address of an AST Service Routine, 

Device Dependent Parameters! 

Up to six parameters specific to the device. Typically these 

are i 

Buffer address 
Byte count 

Carriage control type 
Logical block number 


Any optional 
zeros. 

parameters 

that 

are not specified must 

be filled 

with 

When the QXO 

dl rec 1 1 ve 

1 s 

1 ssued, QIC dl rect 1 ve 

process 1 nq 

code 


receives control and processes the request as follows! 
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It [Perform first level validity cheeks] 

QIQ examines the LUT (Logical Unit Table) In the task header 
for a LUN match. 

It checks If the LUN Is legal for the requesting task. If 
the LUN Is greater than the available LUT slots established 
for the task the directive Is rejected. Given a valid LUN, a 
check la made to determine If a valid UCB pointer exists In 
the LUT for the specified LUN, If none exists the directive 
Is rejected. If the LUN and UCB pointer are valid, the 
redirect algorithm Is entered, 

la, [Redirect algorithm] 

The UCB Is located and the re-direct pointer checked. If the 
re-direct pointer points to the UCB which contains It, then 
the final link in the redirect chain has been found. Else 

the redirect UCB address Is obtained and the test Is 

repeated. This search continues until the last re-directed 
UCB Is found. Then, the backpointer to the DCP Is used to 
locate the OCB and a check on the device name Is made. If 

the name Is TI, then the address of the UCB which Is to be 

used to control I/O transfers Is In the TC8 of the requesting 
task. This pointer was Implanted by MCR when It requested 
the task and the chaining process described links the 
requesting task to the terminal which requested It, If the 
name Is not TI# the final UCB In the redirect chain Is used 
for the I/O Transfer, The EFN and I/O status block (IOSB) 
address are validated and the priority Is Ignored, If any of 
these checks fall, the directive Is rejected. If the checks 
pass* the directive status Is set to +1 and the IOSB# If 
specified# Is cleared, 

2, [Obtain storage for# and create an I/O driver queue entry] 

After the first level checks prove positive# QIQ obtains an 
18-word storage block from dynamic storage. Into this block, 
which we will refer to as an I/O packet# QIO Inserts the 
following (the source of the date Is specified with each data 
1 tern) 


Function Code 

Copied from the DPB 

Contents of the first LUN word 

Established by the redirect algorithm 

Address of the second LUN word 

Calculated from the requesting task's header address 

EFN 

Copied from the DPB 
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P ri orit V 

Copied from TCB of the requesting task 

Address of the Task Control Block 

The TCB address of the requesting task 

Virtual address of the I/O status block 
Copied from the DPR 

Relocation Bias of the I/O status block* 

Cal cu 1 ated 

Address of the I/O status block* 

Cal cul ated 

AST address 

Copied from the OPR 

Device Dependent Parameters 
Copied from the DPR 

3, [Validate the function request] 

Using the 1 ega 1 •» f unc t i on mask in the DCB# QIO determines if 
the requested function is legal. If it is not legal, go to 
9. 

4, [Check for no-op'ed function] 

Using the no*oo # ed function mask in the DCB, check if the 
requested function is to be no*op'ed, If yes# go to 9* 

5, [Check for a Control Function] 

Using the control function mask in the DCB# determine if the 
requested function is a control function. If yes# go to 8, 

6, [Check for a file system function] 

The next tier of function checks determine if the function is 
a file syatem function. If it is# a check is made to see 
whether the device to which the request is directed is file 
structured. If it is we go to 8, If the device is not file 
structured# then the function requested must be either a read 
virtual or write virtual. The request is mapped to its 
logical counterpart (read or write logical) and processing 
proceeds at step 7, 


* These exist to satisfy requirements of the mapped system, A 
separate section will detail the differences between a mapped and 
unmapped system. 
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7, [Transfer function processing] 

If the function Is legal# but not a no*op or control 
function# then 1t # s a transfer function# and address checks 
are made on the buffer# count# and modulus reaul rement s* , If 
any of these fall# qo to 9, 

8, [Packet Queuing] 

QIQ checks the control bits In the UCB which determines If It 
will queue the packet and then call the driver# or call the 
driver and let the driver queue the packet. The call to the 
driver Is via the pointer in the DCB to the driver dispatch 
table entry addresses# namely! 

INITIATOR 

CANCEL I/O 

POWER FAILURE 

DEVICE TIMEOUT, 

In this case the Initiator entry point Is called# and normal 
path QIO directive processing Is complete, 

9, [Function Is Illegal# no«oo # ed# or Invalid parameters] 

If any of these cases pertain# QIQ calls I/O Done and passes 
a status code, A special entry point Is used which causes 
I/O Done to bypass clearing of the unit and controller busy 
flags# clearing of which occurs along I/O Done's normal oath. 

Notes ! 

By reviewing the algorithm for the QIO directive processing# the 
reader should note the care taken to relieve the driver of validation 
processing, It # s through the centralization of validation processing 
that driver code Is substantially shortened and structurally 
simplified, A beneficial fallout of this strategy Is that drivers are 
not called with requests that are going to either fall on a ore»1ssue 
validation check# or not result In the Issuance of an actual I/O (like 
no-op and control functions). This substantially reduces Internal 
overhead. 


3,3,6 Issuing I/O 


* Modulus checks exist for devices which have boundary alignment 
requ 1 rement s. 
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Q.IO calls the driver at the Initiation entry point. We will avoid the 
subtlety of when packet queuing does not occur and assume 1 1 # s queued. 
The driver algorithm is as follows* 

1, [Get an I/O request! 

when the driver 1* called# It Immediately calls the internal 
routine Get Packet (SGTPKT), Get Packet Is discussed In 
Section 3.3.6, 1. SGTPKT either delivers a packet# or returns 
busy. If busy, go to 3, 

2, 11/0 Issue! 

The driver builds the actual I/O order and Issues It, It 
then returns# In this case to QIO, QIO returns the directive 
status to the user Issuing the original QIO directive and 
clears the directive from the stack by returning to the 
dl rec t 1 ve dl soatcher , 

3, [GTPKT returns busy! 

If SGTPKT finds the controller busy# thus making It unable to 
return an I/O packet to the driver# It simply returns a busy 
Indication, The busy Indication simply Informs the driver 
that It cannot at this time Issue an I/O order. The driver 
returns to QI0» which returns the directive status to the 
user Issuing the original QIO directive and clears the 
directive from the stack by returning to the directive 
dispatcher. The original I/O Is In the driver queue# and the 
Issuer ean take appropriate action (waltfor or continue). 


3, 3. 6,1 Get Packet Routine 

Get Packet ($GTPKT) Is called when an I/O driver needs work. This 
occurs following a QIO call on the driver# and after a driver has 
processed an I/O termination, SGTPKT does not know about the 
Initiation cause of a call upon It# It simply attempts to find work 
for the driver and proceeds as follows* 

1, [Scan the driver Q] 

SGTPKT Is passed a UCB address# which It uses to locate the 
SCB and the I/O queue. If the controller Is busy# SGTPKT 
returns busy to the caller. If the controller Is free# a 
queue scan Is begun for the highest priority request that the 
driver can Initiate, Note that the queue Is already In 
priority order and the question to be resolved Is whether an 
entry represents work the driver can do. Also note# that If 
a controller is free# all units on the controller are free. 
Each queue entry must be checked to determine If the unit to 
which It Is directed Is attached. If It Is attached, SGTPKT 
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must check if the attached task Is the same as requesting 
task. If it Is# it returns the packet to the driver. If it 
is not, it continues the aueue scan. It will either find 
work, or return busy. 


3,3,7 Termination Processing 

On an I/O interrupt (specifically a termination in our present 
discussion) the driver is entered directly. The driver first calls 
SINTSV and then SFORK, Or return from SFORK access to shared data 
bases has been linearized and the driver may finish processing of the 
I/O request. The routine that performs this processing is called I/O 
done, 

I/O Done proceeds as follows? 

The controller and unit are gnbusied, (Both the controller and unit 
require busy indicators to enable the Executive to identify the 
eont rol 1 er-uni t busy relationship if a power failure occurs). 

The relocation bias and I0SB address in the I/O packet are used to 
locate the IOSB, If an IOSB was specified then the final status is 
stored, I/O Done then decrements the outstanding I/O count (the I/O 
count is used to prevent task checkpointing if outstanding l/0 # s are 
pending for the task). If the count goes to zero, and the task was 
blocked for I/O rundown, the task is unblocked. 

If a checkpoint request was pending for the task, an internal routine 
is called that will initiate the checkpoi nt i ng process, 

A check is then made to determine if an AST address was specified, if 
not, the I/O packet is released to dynamic storage, a significant 
event is declared# and I/O Done returns to the driver. 

If an AST address was specified, the I/O packet is used for the 
required AST dynamic storage and it is linked into the AST listhead 
for the task, A significant event is declared and I/O Done then 
returns to the driver. On return, the driver will Jump to its 
initiator entry point with the address of the Just unbusied device UCB 
in R5, The initiator calls SGTPKT and the process of looking for work 
begins again. It should be noted that once underway, either by a call 
from QIO, or entry from an interrupt termination, a driver propagates 
its own execution by cycling back to its initiator entry point looking 
for more work. 


3,3,8 I/O Processing Summary 

RSX-llM i/o drives itself from four data structures! 



PAGE 37 


The Device Control Block* 

The Unit Control Block! 

The Status Control Block, and 

The 18*word driver queue I/O packet. 

Centralized routines facilitate both Initiation and termination 
processing. And, finally, the fork structures used by the drivers 
along paths reaulrlng more than 500us of processing both linearize 
access to the I/O data bases, and decrease the non- 1 nt e r rupt 1 b 1 e time 
within the system Itself. 
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3,4 MCR - Monitor Console Routine 

MCR is the collection of functions that make it possible to operate 
and control the RSX»ll M system from a terminal device. As the link 
between the collection of services provided by RSX-11M and users who 
want to make use of these services, MCR provides a number of services, 
spec i f i cal 1 y i 

Services 1*16 run as MCR overlays, 

1, ABOrt 

The task name submitted with the command will be aborted, 

2, ALTer 

The priority of the named task is altered, 

3, CANcel 

Periodic rescheduling is terminated for task name submitted. 
The task itself remains in the STD, and may be active or 
i nact i ve, 

4, DEV ices 

Symbolic names of all devices known to the system are 
displayed on the requesting terminal. The display includes 
any device redi rec t i ons, 

5, EIX 

The named task is fixed in memory. This task cannot be 
checkpointed, and will remain in memory at task exit, 

6, LUN 

A list of Logical Unit Numbers and their associated device 
symbolics is displayed for the task name submitted with the 
commend, 

7, OPen 

Open is used for examination end/or modification of main 
memory, 

8, PARtitions 

This commend outputs a description of each partition and 
subpartition in the system. The list also specifies if the 
partition is a task or common partition. 
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9, RE A s 1 gn 

Reassign de-assigns a Logical Unit Number from one physical 
device and assigning It to another for the named task. 


10, REDIrect 

Redirect makes poslble the redirecting of all I/O reauests 
from one physical device to another having comoatlble 
character 1 sties, 

11, RE M ove 


The task named Is deleted from the STD, The task so removed 
Is unknown to the Executive and exists only as a disk Image, 


12, RUN 

This command enables a task to be scheduled In terms ofl 

a, A delta time from now#or 

b, A delta time from clock unit synchronl zat 1 on# or 

c. Absolute time of day# or 

d. Immediate execution, 

with options a# b# and c periodic rescheduling Is provided, 

13, SAVe 

This command preserves an Image of the RSX-11M Executive on 
disk such that a hardware bootstrap or the BOOt MCR function 
can reload and start up the system, 

14, SET 

Set terminal and device parameters, 

15, TASks 

This command outputs a description of every task which exists 
In the STD, 

16, UNFIx 


Unfix reverses the effect of FIX, 
Services 17-22 run as tasks. 


17. 


BOOt 
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The Boot Command will bootstrap an RSX-11M system from a file 
that was either created by the SYSGEN process or the SAV MCR 
f unc 1 1 on, 

18, DMOunt 

Declares a volume logically off-line, 

1R, INI 1 1 all ze 

Creates an RSX-11M structured volume, 

20, INStall 

The task contained In the file specified In the command Is 
entered Into the STD, and the task header Is Initialized, 

21, MOUnt 

Declares a volume logically on-line, 

22, UFD 

This command creates a User File Directory (UFD) and enters 
Its name Into the Master File Directory (MFD), 


3,4,1 Structure And Operational Environment Of MCR 

MCR Is an RSX-11M task which operates out of a subpartition which Is 
part of a main Partition occupied by the File System*, TKTN, the task 
termination notification task# also operates out of a subpartition of 
the File System partition. The partition Is set up so that the file 
system Is checkpointable and either TKTN or MCR can checkpoint the 
File System, Thus# the file system will be swapped out and MCR 
swapped In when an operator request occurs, 

MCR Is a tree structured task# and its structure Is depicted 
schematically In Figure 3-5, 


* We mean tHat part of the file system referred to 
P r 1 ml 1 1 ves. 


as File 


Cont rol 



PAGE at 


l 

i 

ROOT 

l 

1 


1 

l 

1 1 

l 

l 

1 1 

l 

i 

l 

1 

1 1 

1 

i 

1 l 

l 

l 

DISPATCHER 

PARSERS (1*3) 

COMMAND FUNCTION PROCESSORS 

i 

l 

l 

1 1 

1 

i 

l 1 

1 

l 

l 

l 

1 i 

\ 

l 

l l 

1 

l 


m 

m m 

Figure 3* 

m 

5 MCR 

«• 

T ree 

m m 

St ructure 

m 

w 

The command 

f unct 1 on 

processors 

are 

those 

that process 

the 

f 1 rs t 


console services listed In Section 3,4, The remaining console 
services run as tasks and not as Integral parts of MCR, mcr# in fact# 
does not distinguish between these task functions# and tasks that It 
Initiates as a result of recognizing an MCR reauest for functions 
17*22 listed In Section 3,4, The console language syntax Is defined 
such that If the first three characters of an Input line are not part 
of the defined command language# then MCR will attempt to Initiate the 
task named 


, , , XXX 

Thus# the task named ,,,JIM can be Initiated by entering 
JIM 

to MCR# or by entering 
RUN , , , J I M 

to MCR, 


3,4,2 The Terminal Driver and MCR Initiation 

The terminal driver Is Intimately Integrated Into the ©Deration of 
MCR, Since RSX»11M accepts and acts upon unsolicited Input from any 
operator terminal# It Is the function of the terminal driver to know 
when It Is receiving Input destined for MCR, 

when a character on an operator terminal Is struck# the resulting 
Interrupt Initiates the terminal driver, (Remember the device Is full 
duplex and the keyboard cannot be locked to prevent Input when the 
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device is# in fact# involved in an I/O operation). The driver then 
acts on the input as follows, 

1, [Check the devica state) 

Is, the device busy. No# go to 3, 

2, [The device is busy) 

If the driver was sending output (in an output state) when 
the character was entered# an input request flag is set in 
the appropriate UC9 and the driver continues sending the 
cutout stream. When the output request is finished# 
processing continues at 5, 

If the terminal was in an input state the character is 
accepted. Go to fe, 

3, [Device is not busy) 

Note# if the device was not busy# the incoming character is 
the first character of an input line, 

was the input character a Control-C? (ControNC is an 
explicit request to communicate with MCR), If the character 
was a Control«C# the terminal driver executes a fork and 
execution continues at 4 , 

If the first character is not a Control»C# then a check is 
made to see if the device is attached. If yes# then ignore 
the character (unsolicited input to MCR on an attached device 
is not permitted). 

If the device is unattached then it will be considered the 
beginning of unsolicited input to MCR, Go to 4, 

4, [Fork level processing) 

The driver has transferred to fork level because it needs a 
buffer# and it can only get a buffer at fork level (shared 
system tables must be altered to obtain a buffer). In 
addition to getting a buffer# the fork level terminal 

processing code must check for a rare race condition. 

After the arrival of the Controls (or a non Control»C 
character if the terminal is not attached) and between the 
time the fork is executed end control is regained in the 

driver# it is possible that the device may have returned to 
the busy state. This is because we may have Just unbusied 
the device for a previous request when the input interrupt 
occurred* The interrupt code finds the device free and 

executes a fork, But before control is regained at fork 

level# execution is continued in the driver for the previous 
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request. The driver Jumps to the Initiator entry to 

propagate Its execution and thus may find another welting I/O 
request which It wl 11 begin processing since the device Is 

free# Thus the fork routine must recheck the state of the 

device. If It Is busy the input Is ignored and the driver 
returns (exits) from fork level. Else an attempt is made to 
obtain a buffer for the unsolicited Input, 

5, [Buffer Acquisition] 

If the buffer acquisition attempt Is unsuccessful# the driver 
Ignores the input and exits. 

If a buffer is obtained# the driver sets up to start an 

unsolicited Input request by initialising various pointers 
and setting the status of the controller and unit to buav. 

If the Initial Input character was Control-C# then 

MCR> 

Is echoed to signify an explicit request to Input to MCR, 

Else the Input character Is stored In the buffer and 
echoed on the Initiating terminal. 

The driver returns (exits) from fork level, 

6, [Character processing] 

Once the terminal driver has determined that input coming 
from an operator terminal is destined for MCR# It will 

transfer subsequent characters Into the buffer acquired In 

Step 5, It also echoes the Incoming characters. The 

acceptance of Input will cease If* 

a, ‘The buffer Is filled (the buffer has room for SB 

characters) but the maximum accepted depends on the 
device* 

72 for KSR 

72 FOR VT05B 

80 for LA30S 

80 for IA30S 

b# An end of line character is entered. The valid end of 
1 1 ne characters are* 


Cont rol -Z 
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Carriage Return 

ALT-Mode (codes 33, 175, and 176) 

7, (Interrupt from a character echo] 

Is the device In Input mode? If no go get another character 
from the user output buffer and echo It, If the device Is In 
Incut mode, Is end-of-11ne set? If no re-enable the keyboard 
Interrupt and exit from the Interrupt, If end-of-11ne 19 
detected, then fork, 

8, (End-of-llne processing - fork level] 

Was the Input solicited or unsolicited? For unsolicited 
Input, deposit the UCB address and the terminating character 
Into the Input buffer and link the buffer Into MCR's Input 

oueue, then request mcr to run. The driver Itself clears 

control and unit busy and returns to Its Initiator entry 
point. 

For solicited Input I/O Done will be called. First, the 
number of characters entered Is determined and the buffered 
Input Is moved to the soliciting task's Input buffer. The 
driver Input buffer Is released and I/O Done Is called with 
the second I/O status word eaual to the number of bytes 

entered. The left byte of the first I/O status word is set 

equal to the terminating character and the right byte to *1, 
The driver then Jumps to the Initiator entry Point to 
propagate Its execution. 


3,4,3 MCR Operation 

After the request of MCR by the driver# the file system Is swapped out 
and MCR Is swapped In, Control Is passed to the MCR root segment 
which calls the Dispatcher (DSPTCH) overlay* DSPTCH, via a privileged 
subroutine (SSWSTK), switches to system state. The call to this 
routine Includes a parameter which Is the address where the caller 
wants to return when It switches back to task state. The state 
switching routine performs the switch and resumes processing In the 
caller Immediately following the call. When SSWSTK Is called, It sets 
up an Interrupt entry to the system. Interrupts are locked out while 
It pushes the passed return address and the PS on the stack, SSWSTK 
then calls Interrupt save (SINTSV), On return from Interrupt save R3, 
R2, Rl, R0 are pushed onto the stack and now the stack state simulates 
that of an EMT* SSWSTK now calls the caller who resumes execution one 
Instruction past the call. When the calling routine finishes, It 
returns, which takes It back to SSWSTK, SSWSTK Jumps to Directive 
£x1t which redispatches the processor. The effect of this Is to 
resume the caller In task state at the passed return address. 
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MCR now proceeds as follows! 

1, [Request an unsolicited Incut queue entry] 

The Dispatcher coils the Queue Removal routine ($QRMVF), 
SQRMVF will attempt to remove a buffer and deliver It to the 
Dispatcher. If no buffer Is available (carry set return from 
SQRMVF) the Dispatcher exits. The buffer is formatted as 
shown In Figure 3«6, 


< m m w • W OR D * «■ «* >< mmmm w OR D > < »• • ■ U P TO 8 $ B Y T E S m m m > 


l LINK TO \ UCB OF \ COMMAND INPUT l 

l NEXT BUFFER l INPUT DEV l l 


Figure 3«6 Input Buffer 


The queue empty condition will never occur on an initial call 
to MCR# since MCR is not requested unless something is in the 
queue, MCR will remain resident until it has processed all 
the entries in the unsolicited input queue. 

Note that the Dispatcher# during buffer requisition, is 
operating at system level# and all queue entries are done at 
fork level. Thus, the buffer removal process is linearized 
with buffer Item entry. 

If DSPTCH gets a buffer# it saves the buffer address in a 
memory location and does a return. This return takes DSPTCH 
back to task state where the processing of the buffer begins, 

2, [Process a [Buffer] 

On return to task state# the dispatcher scans through the 
buffer and 


compresses out redundant spaces and/or tabs 
converts an Escape character to a Carriage return 
truncates trailing spaces and/or tabs 

If no line terminator is found in the buffer# a CP is 
inserted as the 80th character. Finally the actual line 
terminator (either CR or ESC) is saved so it can be restored 
in the message if the message must be routed to a task other 
than MCR itself. 

The dispatcher then converts the first three characters to 
RAD50 and begins to search two internal tables for an MCR 
function with a matching name. 
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[Searching the function tables - Table descriptions] 

MCR has two function tablesj one for privileqed commands# and 
one for non*pr i v i 1 eged commands. 

Privileged commands are those whose unrestricted use could 
cause privacy violation or system failures and they can only 
be executed from a privileged terminal. Privileged terminals 
are identified by a bit in the UCB, These terminals are 
established at SYSGEN or by the SET command. 

Both tables contain a 5-word packet for each command in the 
class (privileged or non-pri vi 1 eged) , The packet appears in 
Figure 3-7 # 


m m 

i 

RAD50 

CMD NAME (3 

CHARS) 

m m 
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INTO COMMAND 
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I 
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m m 
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INTO COMMON 

OVERLAY 
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Figure 3-7 * Function Table Entry 


The table is designed with the assumption that a given mcr 
function would not require more than three overlays to carry 
out its intent# Thus# the table entries correspond to three 
overlay types! 

Command overlay# 

Parser overlay# and 

Common overlay. 

The use of these overlay types is in general observed, but 
exceptions occur and they will be noted. 

Typically# any command that can be processed in a single 
overlay# and whose size is such that it requires all or 
neerly all of the max overlay size (600 wds) will b© classed 
as a command overlay. 

Parsers for the commands are distinct entities and are 
grouped into overlays. Generally# a given parser services 
more than one command but three parsers currently service all 
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the commands. The parser entry is a pointer to a parser 
table entry shown in Figure 3-8, 


m m 

l 

RAD58 

PARSER 

NAME 
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* * 
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m m 
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INTO 
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m m 


Figure 3«8 • Parser Table Entry 


Since three parsers service all the commands it is more 
economical in storage space to point to the parser table 
rather than include the name and the index in the main 
function table. 

The index is used as the entry point into the parser where 
the parsing for a given command begins. This is required 
since a parser can, and generally does, contain parsers for 
more than one command. 

The common overlay is used when the processing for a command 
is small enough to make it practical to group more than one 
command into a single overlay. This grouping saves space 
since ten words are required by the Overlay Runtime System 
for each overlay in a tree structure. The Index serves the 
same purpose as the index in a parser overlay. 

Note that a command overlay also contains an index. The 
value of the command overlay index is generally zero* But to 
maintain the coherence of the table processing commonality, 
and to allow for flexibility, the index is included, 

3a, [Look up and start a function other than an MCR internal 
f unct i on] 

The dispatcher than looks in the privileged command ^able for 
a name which matches the first three characters in the input 
buffer. This table contains all the privileged MCR commands. 
These are noted in the commands listed in Section 3,4,1, 

Internally, privileged terminals are identified by a bit in 
the UCB, The bit is set at 3YSGEN or from a privileged 
terminal using the SET MCR command. 

If the command is not found in the privileged command table, 
the non-pr i v i 1 eged command table is searched. 

If the name is not in either table, then the dispatcher will 
prefix three periods to the three buffer characters and using 
these six characters will search the STD looking for a match 
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on the name, If It does not find the name it will display an 
error message on the Initiating terminal. If It finds the 
name# It will request the function to run# supplying as an 
argument to the requested task the UCB address that was In 
the Input buffer. The UCB address Is Inserted Into the TCB 
of the requested task as Its TI (terminal Input) oseudo 
device. If the attempt to request the task falls an error 
message Is displayed# the buffer is released and mcr exits. 
Having discovered a non-internal MCR function# MCR must 
prepare to pass the buffer# since the Initiated task Is going 
to Issue a GET MCR COMMAND LINE directive. To pass the 
buffer MCR uses three words in System Common, These words 
arei 

1, The TCB address of the requested task! 

2, The address of the- command buffer# and 

3, The byte count of the number of Input characters In 
the buffer, 

MCR fills these words# making synch ron 1 z 1 ng checks that they 
are free# since only one triplet exists for passing buffers 
to a requested task. Thus# until the buffer Is emptied# 
other completed buffers In the queue will be waiting. 

Eventually (and this should be soon) the requested task will 
start running# and Issue a GET MCR COMMAND LINE directive. 
The directive processing then tests for a match on the TCB 
address In SYSCM and the TCB address of the requesting task. 
If they match the buffer Is passed to the task by copying It 
Into the DPB of the directive. The directive status Is set 
to the byte count# the buffer Is released and the TCB address 
In the SYSCM triplet Is cleared. The TCB address being zero 
Is an Indication to MCR that the triplet Is free, 

3b, [Start an Internal MCR function] 

Once a name match has been found In the command table# the 
Dispatcher copies words 1# 2# 4 and 5 of the function table 
entry and both words of the parser table entry for this 
command Into the mcR root segment. Now the Dispatcher scans 
the function table entry as follows* 

3c. IF 


A parser exists 


THEN 


Go to 4 
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ELSE 


IF 


a command overlay exists 


THEN 


Go to 3d 


ELSE 


IF 


a common overlay exists 

THEN 

Go to 5 

ELSE 

Abort 

3d. Form overlay name# construct reaulred overlay Information 
packet# and enter the root at the point where overlay loading 
Is performed, 

а, (Parser functions! 

The selected parser will parse the buffer and# If the parse 
Is successful# It will Jump back to the root to load the 
desired function. If the parse falls# the parser deposits an 
error number In the root and Jumps to the entry SERLD In the 
root which loads the error overlay. 

Ultimately the root will Initiate another routine, either the 
error routine or the requested function, 

5, [Function routines] 

These routines may further check the Input and find errors. 
If errors are found# the function sets up the error routine 
and Jumps to the root to load an error overlay. If It 
succeeds# the function will release the buffer and enter the 
root at the point where the root will reload the dispatcher, 

б, [Error Overlay] 

The error overlay contains all error messages and the code 
needed to format the error message from the error number 
deposited In the root by the MCR component discovering the 
error. 
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7. (Final Exit] 

The dispatcher calls the queue routine to obtain another 
buffer# if one is found the cycle of name table scanning 
resumes (starting at step 2D, If no buffers are waiting, MCR 
exits. 


3,5 Partitions 

The user area of RSX-llM is divided into partitions. In unmapped 
systems tasks are bound to a specific partition and must execute from 
that partition. In mapped systems tasks may be installed and 
subsequently executed in any partition provided the partition is large 
enough and sufficient checkpoint space is available in the task image, 

A partition always consists of at least a main partition* the main 
partition can be subdivided into as many as seven subpartitions. The 
execution of tasks within the main partition and its subpartitions is 
mutually exclusive. This means that If a task is executing in the 
main partition no tasks may be executing In any subpartition of the 
main partition, Cont rarywi ae, if a task is executing in a 
subpartition no task requiring the main partition may be executing. 
The subpartitions, however, can all execute in parallel. 

Subpartitions exist so as to make it possible to reclaim and subdivide 
large Partitions that service nonrealtime tasks like language 
t ransl ators. 

If a main partition task is fixed In memory then no other main 
partition or subpartition task may execute until the task is unfixed, 
A fixed subpartition task will exclude the execution of a main 
partition task and other tasks wanting to execute from the subject 
subpart i t i on. Other subpartitions operate independently. 

An identical set of conditions apply to tasks that are not 
checkpoi ntabl e. 

The manipulation of a partition and its aubpart i t 1 ons becomes more 
intricate when the tasks occupying them are not fixed in memory and 
are checkpointable. Any number of tasks can be waiting for use of the 
partition or subpartition. Given that no tasks running out of a 
partition are fixed in memory# and that all are also checkpointable# 
the sole determiner of which queued tasks waiting for the Partition 
will run is pri or 1 1 v. 

When a task is requested it is entered into the appropriate partition 
wait Queue and a sequence is initiated to determine if the existence 
of this task in the partition wait queue will reauire checkpoi nt 1 ng of 
+ he task currently occupying the Partition, If the task entering the 
wait queue is of higher priority then that of the current task, 
checkpointing will proceed. 
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When a task that Is not fixed In memory exits, the partition, wait 
queue for the partition being freed is examined for the highest 
priority task waiting for the partition# and when located this task Is 
loaded and put Into active competition for processor resources. 

Before proceeding to the detailed algorithms used to service a 
partition the key concepts are listed below! 

w A partition consists of a main Partition and up to seven 
subpart 1 1 1 ons, 

* Execution between a main partition and Its subpa r t 1 t 1 ons la 
mutual 1 y exc 1 usl ve, 

* Execution among subpartitions mav proceed In parallel, 

* Tasks fixed In memory or not checkpointable lock up the 
partition or subpartition from which they are executing, 

* Any number of tasks mav be waiting for a partition, 

* Task access to a partition Is based on priority. Tasks not 
fixed In memory or not checkpointable will be rolled out to 
make room for higher priority tasks waiting to occupy the 
partition. 


3,5,1 Partition Control Data Structures 

The data structures which service the partition concepts outlined 
above are shown in Figure 3*9, 
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Figure 3*R - Partition Data Structure 


The very composition of the structure provides Insight Into both the 
extent of the service and how Internally the service Is prooagated to 
the user level. 

A word Is maintained In system common CSPARHD) that oolnts to the 
first main Partition Control Block (PCB) In the system. From this PCB 
are linked the PCBfa for any subpartitions defined for this main 
partition. All PCB's defining other partitions and subpart 1 1 1 ons are 
similarly linked. The last PCB Is a subpartition PCB except In the 
case where there are no subpartitions of the subject main partition. 
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In this ease the main partition PCB links to the next main partition 
PCB, The data structure Is then reDeated until we run out of PCB # s to 
link together* Notice that the TCB # s of tasks waiting to occupy 
either the main partition or a subpartition are always linked from the 
main partition PCB, The TCB's are ordered by priority and each 
contain a pointer to the PCB of the partition for which they are 
wal t 1 ng. 

The scheduling of a partition Is done by the next task ( SNXT5K ) 
routine. It Is the function of SNXTSK to select the next task In the 
list of TCB # s linked from the main partition wait queue that Is to 
occupy the main partition or a subpartition of the main partition. 
Note that this process Is Independent of which task In the system will 
gain control of the CPU next. 

There are four specific events which can result In a change of control 
In a partition, 

1, Task exit of a nonflxed task, 

SNXTSK must now look for another task welting for the 
partition, 

2* The loader has completed bringing a task Into memory, 

A new task Is now ready to compete for the Processor, 

3, An Initiation type request occurs. 

This can bei 

a, A RUN command from a terminal , 

b, A RUN or REQUEST Executive directive. 

In this ease several checks must be made by SNXTSK, (we will 
discuss these checks shortly) 

4, The outstanding I/O count for a checkpointable task waiting 
for swap out has gone to *ero. 

The loader must checkpoint the task and then call SNXTSK to 
select the next task to occupy the Partition, 

Given these prel 1 ml nar 1 es we can now examine the algorithms used to 
service partitions. 


3,5,2 Partition Algorithms 

1, (servicing Initiation requests] 
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1 3 the reauested task active or currently being fixed in 
memory? If yes, return carry set, (The request is redundant 
since the task is either running or in process or being 
set»up to run). 

If the task is in memory, it is fixed in memory and a 
partition allocation pass is not required. The following 
task set up is performed. 

An initial stack is constructed that will cause the task 
to start executing at its transfer address. 

The task status word is set to active# 

A conditional schedule request is set that will force 
redi spetch i ng of the processor if the task Just made 
action is of higher priority than the currently running 

task. 

If the task is not in memory, then it is entered by priority 
in the Partition Wait Queue and SNXTSK is executed. 

It should be noted that a task f i xed» i n»memorv remains 
physically in control of memory even if the task exits, A 
task that is not f i xed" i n»memory is removed from memory at 
task exit thus freeing the memory in which it resides, 

2, [SNXTSK « Select the next task to run in a partition] 

SNXTSK begins a scan of the main partition wait queue seeking 
to determine if the partition, for which a task is waiting, 
is free. Note that a given task is not necessarily the one 
most recently inserted into the partition wait queue. 
Examination of the partition data structure will reveal that 
all TCB # s, both for main and subpart i t i ons, are linked from 
the main partition wait queue, 

SNSTSK checks if the partition is free. No, resume 'scan. 
Yes# insert the TCB address into the PCB declaring ownership 
of the PCB, Set the busy flag in both the main and 
subpartition. Remove the TCB from the partition wait queue# 
insert it into the loader queue, 

A TCB is always linked into the STD, A given TCB may also be 
linked into either the 1 oade requeue or the Partition wait 
queue. 

The loader is then requested and SNXTSK tries to allocate 
another task within the partition. The allocation process 
continues until either all waiting tasks have been assigned 
to partitions or an allocation failure occurs. 



PAGE 55 


3, [SNXTSK Checkooi nt 1 ng - Wain partition reauests] 

whenever SNXTSK finds a task waitinq for a wain partition 
that Is busy It must make a checkpoint decision. For a main 
partition request# it proceeds as follows! 

3a, Is the task waiting for the main partition of sufficient 
priority to pre-empt the task currently occupying the main 
partition or a subpa rt i t i on j no exit, the partition cannot be 
allocated to the waiting task, 

3b, Is the task occupying the partition in any of the following 
states? 

Not checkpointable 
Fixed in Memory 
Being Fixed in Memory 

If yes# exit the partition cannot be allocated to the waiting 
task. No# go to 3a and check the next subpartition. 
Eventually# either every subpartition is found to be 
checkpointable# or the main partition cannot be freed and 
SNXTSK exits, 

3c, [Checkpointing subpartitions] 

Once SNXTSK determines the main partition can be made 
available by checkpointing the tasks in the subpartitions it 
starts the checkpoi nt 1 ng process as follows! 

Is the I/O count for the task occupying subpartition *0# No# 
go to 3d, Yes# execute the checkpoint initiation routine. 

Move the TCB occupying this partition into the loader aueue# 
set a bit establishing the task is checkpointed# and reauest 
the loader. No further action on this subpartition is taken 
until the loader recalls SNXTSK after the checkpointing 
process is completed# 

3d, Set a bit which indicates the task is to be checkpointed when 
its I/O count reaches 0, (This bit is tested by I/O Done# 
and If set# I/O Done calls the checkpoint initiation routine 
in 3c above). 

4, [SNXTSK checkpointing • Subpartition reauests] 

If a subpartition Is requested the essentials of the 
algorithm in 3 above is followed# but only the requested 
subpartition need be checked. 
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5teps 1«4 complete the description of partition management. But since 
the loader is intimately involved with the algorithms# it will be 
described in this section. 


3,5,3 The loader 

The loader# which is a resident RSX-llM system task# has three 
f unct 1 ons t 

1, loading new tasks (initial reading of disk lmage)i 

2, Checkpoi nt 1 ng tasks (writing task checkpoint image to disk)# 
and 

3, Resuming checkpointed task (reading task checkpoint image 
back from disk). 

The loader has a single objective! to empty the aueue of tasks waiting 
for its attention. The queue is serviced FIFO and 2 bits in the task 
status word# the checkpoint bit and the out of memory bit# determine 
the loader action on an entry, 

CKPT on 
OUT OF MEM on 

The task is read back into memory from its checkpoint area* 
CKPT on 

OUT OF MEM off 

The task is written from memory into its checkpoint area, 

CKPT off 
OUT OF MEM on 

The task is read into memory from its load image, 

CKPT off 

OUT OF MEM off 

This combination la Illegal, 

When the loader removes the next entry from its queue# it assumes 
memory is available if the task is to be read* after the loader writes 
a task into its checkpoint area Release Partition is called which in 
turn calls# $NXTSK to select the next task that will occupy the 
part 1 1 1 on. 

On reading a task into memory# the loader! 

1, Marks it In memory (1,e, clears OUT OF MEM)# and 

2, Builds a initial stack (on initial reeds only) 
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Tke marking of the task in memory has the effect of unblocking the the 
task so it can compete for system resources. As soon as a task is 
requested it is considered initiated. It will not compete for system 
resources however, until the loader marks it in memory. After 
completing the service for a queue entry the loader looks for more 
work, and when the queue is empty, it exits. 

Though the loader and SNXTSK call each other they are almost totally 
ignorant of each others function. The call from the loader to SNXTSK 
is such that SNXTSK can't distinguish it from other events that 
trigger SNXTSK, And, the loader makes very few decisions as evidensed 
by the fact that the description of its algorithm is best presented in 
narrative form. 
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-t.0 FAULT ISOLATION - SOME GENERAL HINTS 


4,1 Introduction 

Though RSX» 1 1 M is a real time# multiprogramming system, it ha9, in the 
real memory version, no "brickwall'* protection. The basic machine 
configuration which RSX-11M supports, has only a single program state, 
and no memory protection. The lack of these features simoly mean that 
the user state tasks can fault such that the system itself faults. In 
these c i rcumstances, it becomes extremely important to develop the 
skills and discipline needed to rapidly isolate the source of a system 
failure. This section is a first attempt at recording the experience 
gained thus far in isolating software faults that occur in RSX-11M, 
Ultimately this section should evolve into a handbook for field 
software specialists. To reach this much needed state, it will 
require inputs and suggestion from all members, of the RSX-llM team. 


4,2 Fault Classifications 

Three culprits can be identified when the system faults* 

1, A user state task has faulted such that it causes the system 
to fault* 

2, The RSX-UM system software itself has faulted, or 

3, The host hardware has faulted. 

The immediate action on the part of the Programmer subject to one of 
these errors is to determine which of these three cases is the source 
of the fault. Our prime concern will be the procedures which may help 
the programmer uncover the fault source. The repair of the fault 
itself is assumed to be the programmers responsibility. 

Faults manifest themselves in roughly three wavs (and they are listed 
here in order of increasing difficulty of isolation) 

U The system displays the CRASH pr.into.ut and halts. The CPaSh 
printout is discussed in Section x,x, 

2, The system halts but displays nothing, 

3, The system is in an unintended loop* 


Immediate Servicing 
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■fc $ X • 1 1 M can be built to contain resident crash reporting and Panic 
dump routine#* and our comment# assume such a system, (It should be 
noted that the minimal system will not have space for these routine#,) 

The Immediate aim# regardless of the fault man 1 f est at 1 on, Is to 
Initiate the crash reporting and panic dump routines. 


4,3,1 Case 1 - The System Has Displayed the Crash Printout 

In this case, all the basic Information describing the state of the 
system has been displayed. We will pick up the actual Crash printout 
after we have described how to Invoke Panic Dump for cases 2 and 3, 


4,3,2 Case 2 - The System Has Halted » No Information Displayed 

Before taking any action preserve the current PS and PC (1,e, examine 
and record). The procedure depends on the particular PDPMi 

processor. For all processors# the PC Is displayed In the address 
register. The PC can also be obtained as follows? 

For an 11/45 

1, Enter a 7 In the console Switch Register 

2, Depress load Address 

3, Depress Register Examine 

4, The PC Is displayed In the data lights. Record the PC, 

For an 11/40 or 11/10 

1, Enter 777707 In the console switch register 

2, Depress Load Address 

3, Depress Examine 

4, The PC Is displayed In the data lights. Record the PC, 

Now obtain the PS# the procedure for which, Is Identical In all 
systems, 

1, Enter 777776 In the console switch register 

2, Depress Load Address 


3, 


Depress Examine 
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a* The PS Is displayed In the data lights, Record the P$. 

Next Invoke the Panic Dump routine by entering 40(8) In the switch 
register# Depressing Load Address# and then Start, 

40(8) Is the address of a JMP to the Panic Dump Routine In any RSX-11M 

system. 

The Panic Dump saves R0-R6 and then halts awaiting dump limits to be 
entered via the console switch register. The PS Is cleared when START 
Is depressed# and the original PC Is destroyed. Thus the Importance 
of recording these vital pieces of debugging Information before 
Initiating the Panic Dump, 

Dumps of selected blocks of memory may be obtained using the following 
procedure t 

1 - Enter the low dump limit In the console switch register and 

depress continue. The processor will Immediately halt again, 

2 • Enter the high dump limit In the console switch register and 

deoress continue. The dump will begin on the device whose 
CSR address Is DSSBUG (usually 177514 which Is the line 
printer). At the end of the dump the processor will again 
halt awaiting the Input of another set of dump limits. 

To reach the same status arrived at with crash reporting In 
Case 1 above# enter the dump limits 0-520(8) when the panic 
dump first halts. This will dump the system stack and the 
registers. 


4,3,3 Case 3 • System Is In An Unintended Loop 
P roceed as foil owst 

Halt the processor 

Record PC# and PS as In 4,3,2 above. 

After recording the PS and PC# the programmer may want to step through 
a number of Instructions In an attempt to locate the loop. 

After the attempt to locate the loop transfer to the panic dump 
routine as In Case 2, 

This brings us to an equivalent status for the three fault situations. 


4,4 Other Pertinent Fault Isolation Data 
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Before proceeding with the task of locating the fault* the programmer 
is strongly advised to dump system common (SYSCM), He can accomplish 
this by looking for the file SYSCM in the Executive load map listing 
and entering the appropriate limits to the Panic Dump Routine* SYSCM 
contains a number of critical pointers and listheads. 

In addition the programmer should dump the dynamic storage pool and 
the device tables* The dynamic storage region is the module INITl and 
the device tables are in SYSTB, 

The programmer now has! 

PS 

PC 

The Stack 
R 0»R 6 

The Dynamic Storage Region 
The Device Tables# and 
System Common 

This data is a minimal requirement for effective fault isolation. If 
an individual programmer plans to consult with other group members on 
the source of a fault# he should do so only after he has collected 
this data. Eventually# we will require that all SPR # s supply this 
i nf ormat i on. 


4,5 Fault Tracing 

Three pointers in SySCM are critical in fault tracing, 

SSTKDP • Stack Depth Indicator 

This data item will indicate which stack was being used at the 
time of the crash. As will be seen# this plays an important role 
in determining the origin of a fault. The following values 
apply, 

+1 » User (task state) stack 
0 or less - System stack 
STKTCB • Pointer To the current Task TCB 

This is the TCB of the user level task in control of the CPU, 



PAGE 62 


SHEADR * Pointer To The Current Task Header, 

Locating the Header provides some other useful data. The first 
word in the header is the users stack pointer the last time it 
was saved. If the Stack Depth is + 1 then the user has managed to 
crash the system. In a system with brickwall protection (for 
example, the mapped RSX»11M system), the user should not be able 
to crash the system. Even if the user stores in the Executive, 
the crash will not occur until the state is switched and then the 
system will crash. Such a fault may prove difficult to locate. 

If the user branches wildly into the Exec it will terminate the 
user task, but the system will continue to function (possibly 
er roneous 1 v ) , Knowing the users stack pointer provides one more 
link in the chain which may lead to the resolution of the fault. 


4,5,1 Tracking Faults Following An Automatic Display Of The System 
State (Case 1) 

First examine the system stack pointer. Usually an Executive failure 
is the result of an SST type trap within the Executive (other than the 
specialized use of the trap i nst rue t i on) , 

If an SST does occur within the Executive, then the origin to the call 
on the crash reporting routine will be in the SST service module, 
(The crash eall is initiated by issuing an I0T at a stack depth of 
zero or less,) 

A call on crash also occurs in the Directive Dispatcher when an E^T 
was issued at a stack depth of zero or less# or a trap instruction was 
executed at a depth of less than zero. The stack structure in the 
case of an internal SST fault is as follows! 
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m m 

l 

PS 

l 

l 

PC 

l 

l 

R5 

l 

l 

R4 

l 

t 

R3 

l 

l 

R2 

\ 

i 

R1 

l 

l 

R0 

l 

l 

ZERO OR MORE SST PARAMETERS 

l 

i 

SST FAULT CODE 

l 

l 

m m 

NUMBER OF BYTES 

1 

m m 


Figure 4-1 


The PC points to the Instruction following the one which caused the 
SST failure. The number of bytes Is the number of bytes that are 
normally transfered to the user stack when the particular type of SST 
occurs. If the number Is 4' then Just the PS and PC are transfered 
and there are no SST parameters. The definition of each fault code 
can be found In the file A80DF, 

If the failure Is detected In SDRDSP the stack is the same as Figure 
4-1 except the number of bytes# SST fault code# and SST parameters are 
not present. The crash report message# however# will Indicate the 
failure occurred In SDRDSP, 

There Is one SST-type failure that will not have the stack structure 
of Figure 4»l and that Is stack underflow. To distinguish the two 
cases# determine where the crash actually occurred. If It occurred In 
SDRDSP# or was a normal SST crash# then Figure 4-1 Is the stack 
structure preserved. If It was a non-normal SST# then Figure 4-2 is 
the preserved structure. 
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l 

PS 

\ 

1 

PC 

l 

Figure 4-2 


Non-normal SST failures occur when It is not possible to push 
information on the stack without forcing another SST fault, when this 
occurs# a direct Jump to the crash reporting routine is made rather 
than an IOT crash, The PS and PC on the stack are those of the actual 
crash# and the address printed out by the crash reporting routine is 
the address of the fault rather than the address of the IOT that 
crashes the system. Note that the crash reporting routine removes the 
PC and PS of the IOT instruction from the stack which in this case is 
incorrect. Thus the stack pointer will appear to be 4 greater than it 
really is (i,e, as in figure 4-2), 

The programmer now has all the information he needs to isolate the 
cause of the failure. From this point on he must rely on his own 
experience and knowledge of the interaction between his program and 
the services provided by the Executive, 


4,5,2 Tracking Faults When The Processor Halts without Providing A 
Fault Display 

Tracking starts with an examination of SSTKDP# STKTCB# and SHEADR* 
The difficulty in tracking failures in this case is that the system 
stack is not directly associated with the cause of a failure. 

By examining SSTKDP# one can determine the system state at the time of 
failure. If it was in user state, the next step is to examine the 
users stack. The examination process focuses on scanning the stack 
for addresses which may turn out to be subroutine links which will 
ultimately lead to a thread of events isolating the fault* This is 
essentially the same aim in looking at the system stack if SSTKDP is 
zero or less. 

Frequently a fault will occur such that the SP points to Top of Stack 
CT0S)+4 # This results from issuing an RTI when the top two items on 
the stack are datai this will result in a wild branch# then# most 
probably# a halt. Figure 4.3 shows a case# where two data items are 
on the stack when the programmer executes an RTI* 

TOS points to a word containing 40100, Suppose that location 40102 
contains a halt. This indicates that the original SP was four bytes 
below the final SP and fault tracing should begin from the previous 
SP, 
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l 

1 < » « S P 

l 

51 

1 

40100K--SP 


Figure 4-3 


4,5,3 Tracking Faults when An Unintended Loop Has Occurred, 

After halting the processor# we are roughly In the same state as the 
proceeding section. Some specific suggestions are to check for a 
stack overflow loop. Patterns of data successively duplicated on the 
stack Indicated a stack looping failure. 

The console lights may also Indicate the origin of a problem, A 
tight# glimmering pattern may Indicate hardware# while a blinking# 
more elongated# yet repetitive pattern may Indicate software. 
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5.0 DATA STRUCTURES 


5,1 Partition Control Block (PCB) 


P.LNK 

1 

PCB LINK WORD 


l 

O 



P,NAM 

l 

PARTITION NAME 


l 

2 




1 

(RADIX 50) 


J 

a 



P , SU8* 

1 

PNTR TO NXT SUB-PARTITION 

PCB 

\ 

6 



p,main 

1 

POINTER TO MAIN PARTITION 

PCB 

l 

10 



P.REL 

1 

PHYSICAL ADDRESS 


l 

12 



P.SIZE 

1 

SIZE OF PARTITION IN BYTES 

1 

14 



P.WAIT 

1 

PARTITION WAIT QUEUE 


i 

16 




1 

LISTHEAD 


l 

20 



P , BUSY 

l 

PARTITION BUSY FLAGS 


l 

22 



P , TCB 

l 

TCB ADDRESS OF OWNER 


l 

24 



P, ST AT 

1 

PAR STATUS 1 # APR'S TO 

LOAD l 

26 


MAPPED 
SYSTEM 
nwi y 

P,PDR 

i 

CONTENTS OF LAST PDR 


1 

30 

1 

1 

i 

m m m 

P.HDR 

1 

* 

ADOR OF HDR IN MAPPED SYSTEM 

1 

s m 

32 

UnU T 


5,1,1 Partition Control Block Details 
P.LNK 


Deacri pt i on« 

Pointer to next partition. The PCB's are linked in physical 
address order, highest to lowest. If a main partition has 
subpart i t i ons these are linked in the PCR chain off the main 
partition in highest to lowest address order. The last 
subpartition of a main partition will either end the PCB 
chain or link to the next main partition, A main partition 
with no subpart i t i ons either links to the next main partition 
or ends the chain. 
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Inltlallzatlon/Acceas! 


P.NAM 


Descrl d t 1 on | 

Radix 50 partition name, 
Inltlallzatlon/Aceessi 


P.SUB 

Description! 

Points the next subportion. Structured and used anelgously 
to P,lNK when manipulating a chain of subpartition PCB's, 

Initial Izatlon/Accesai 

P , M A I N 

Description! 

Backpointer from a subpartition to Its parent main partition. 
Initial izati on/ Ac cess I 


P.REL 


Description! 

Partition base relocation bias. In a mapped system P,REl Is 
the bias! In an unmapped system, P,REL Is the actual 
partition address. 

Ini 1 1 al 1 z at 1 on/ Access ! 

P,HDR (unmapped System only) 

Description! 

Task Header pointer. 


P.SIZE 

Descript 1 oni 

Size of partition In bytes, 
Inltlallzatlon/Access! 


P.WAIT 
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Description* 

A pointer to a Hat of tasks awaiting the use of the 
partition* The list is ordered bv priority and is searched 
to determine which task should be in control of the 
part i t i on. 

Initial ization/Access* 

P * BUSY 

Oeac r i ot i on i 

A two byte field* The first byte# the busy status# is the 
inclusive or of the state for the main partition and all its 
subpartitions. The second byte# the busy mask# contains a 
busy(l) not busy(0) setting for the main partition and its 
seven subpart i t i ons. 

Initial ization/Access* 

Under complete control of the set command processor. 


P.TCB 


Description! 

TCB address of partition's owner 
Initial ization/Accessi 
P , ST AT 

Descript 1 oni 

The status bits have the following meaning* 

Bit Symbolic Meaning 

0**2 PS, APR Starting APR number for non-PIC libraries 

3 Reserved 

4 Reserved 

5 Reserved 

6 PS,PIC Library is Position Independent lcYes 

7 PS, COM Partition is a COMMON/LIBRARY partition 

Ini t i al i sat i on/Access i 
P , N APR 


Desc r i pt i on * 



Number of APR's to load. 
Initial Izatlon/Accessi 
P.POR (maoped systems only) 

Oescrl pt 1 om 

Contents of the last PDR, 
InltlaHzatlon/Aecesst 
P,HDR (mapped systems only) 

Desc r 1 pt 1 on i 

Address of the Task Header, 
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5*2 Task Control Block 


T , INK i UTILITY LINK WORD l 0 

T.PRI - 

T.IOC 1 I/O C NT 1 PRIORITY l 2 

T , TCB l AODRESS OF THIS TC8 J a 

T.NAM j TASK NAME i 6 

IN 

I RADIX50 l 10 

T.RCVL I l 12 

RECEIVE LISTHEAD 

I 1 14 

T.ASTL 1 l 16 

AST LISTHEAD 

I l 20 

T.EFLG 1 TASK LOCAL i 22 

....... EVENT FLAGS 1-32--- 

1 1 24 

T , UCB 1 UCB AOOR OR REQUEST TERMINAL \ 26 

T.TC8L 1 TASK LIST THREAD WORD l 30 

T , ST AT 1 TASK STATUS WORD I 32 

T , LBN • LOGICAL BLOCK i TSK STATUS EXT l 34 

.« — . .................... 

I NUMBER OF TASK LOAD IMAGE I 36 

T.LOV J UCB ADDRESS OF LOAD DEVICE I 

T.PCB I PCB ADDRESS OF LOAD PARTITION | «2 



TASK STATUS WORD BIT DEFINITIONS 


BIT SYMBOLIC 


0 

TS.CKD 

Checkpoint Disable 

layes 

1 

TS.CKR 

Checkpoint Request 

1 ayes 

2 

TS.CKP 

Checkpointed 

1 ayes 

3 

T5 , OUT 

Out of core 

1 = yes 

a 

TS.FXD 

Fixed In memory 

i*yes 

5 

TS.BFX 

Task Being Fixed 

1 ayes 

6 

TS.CHK 

Task checkpointable 

0ayes 

7 

TS * AST 

AST In progress 

layes 

6 

TS , ACP 

Ancillary control processor 

1 ayes 

9 

Reserved 


10 

Reserved 


11 

TS , REM 

Remove task at exit 

layes 

12 

TS t MSG 

Abort Message being cutout 

1 ayes 

13 

TS.OST 

AST recognition disabled 

layes 

14 

TS.RDN 

I/O rundown in orogpess 

layes 

15 

TS , EXE 

Task In execution 

0ayes 


TASK STATUS EXTENSION BYTE BIT DEFINITIONS 
BIT SYMBOLIC 


0 

TS.WFR 

Task 

In WAITFOR 

layes 

1 

TS.SPN 

Task 

suspended 

layes 

2 

none 

Saved 

TS.WFR on AST 


3 

none 

Saved 

TS , SPN on AST 


a 

TS.MCR 

Task 

requested as mcr function 

layes 

5 

TS, ABO 

Task 

marked for abort 

layes 

6 

TS « PR V 

Task 

Is prl vl 1 eged 

layes 

7 

ts.hlt 

Task 

being halted 

1 ayes 



PAGE 72 


5,3 Task Header 


m m 

H.CSP l 

CURRENT SP 

* m 

i 0 

H.HDLN J 

HEADER LENGTH IN BYTES 

1 2 

H.PCBT l 

TASK PCB ADDRESS 

l a 

l 

LOW VIRTUAL ADDRESS 

i 6 

l 

HIGH VIRTUAL ADDRESS 

i 10 

l 

ACCESS l USER PDR 

l 12 

H.PCBC 1 

COMMON PCB ADDRESS 1 

i 14 

l 

LOW VIRTUAL ADDRESS 

l 16 

\ 

HIGH VIRTUAL ADDRESS 

i 20 

i 

ACCESS 1 USER PDR 

l 22 

l 

COMMON PCB ADDRESS 2 

1 24 

l 

LOW VIRTUAL ADDRESS 

l 26 

l 

HIGH VIRTUAL ADDRESS 

l 30 

i 

ACCESS l USER PDR 

l 32 

i 

COMMON PCB ADDRESS 3 

l 34 

l 

LOW VIRTUAL ADDRESS 

l 36 

l 

HIGH VIRTUAL ADDRESS 

l 40 

l 

ACCESS l USER PDR 

l 42 

l 

0 END OF PCB'S (SENTINEL) 

l 4a 

H.DSW l 

SAVE AREA FOR TASK DSW 

l 46 

H.FCS l 

FCS IMPURE POINTER 

1 50 

H, FORT l 

FORTRAN IMPURE POINTER 

l 52 

H.OVLY l 

OVERLAY IMPURE POINTER 

t 54 

H.RSVD i 

■a at 

RESERVED 

l 56 

m m m 



EVENT FLAG MASK WORDS 


i 60 
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l 

FOR EVENT FLAGS 

l 62 

l 

1-64 

l 64 

l 1 66 

H.CUIC 1 

CURRENT TASK UIC 

\ 70 

H.OUIC l 

DEFAULT TASK UIC 

l 72 

H.IPS l 

INITIAL PS WORD 

l 74 

H.IPC l 

INITIAL PC WORD 

\ 76 

H, ISP 1 

INITIAL SP 

l 100 

H t OOV A l 

ODT SST VECTOR ADDRESS 

l 102 

H.ODVL l 

ODT SST VECTOR LENGTH 

l 104 

H.TKVA l 

TASK SST VECTOR ADDRESS 

106 

H.TKVU l 

TASK SST VECTOR LENGTH 

l 110 

H.PFVA J 

POWER FAIL AST 

1 112 

H.FPVA \ 

FLOATING PNT EXCPN AST 

i 114 

H.FPSA l 

P OR EAE REG SAVE AREA A DDR 

l 116 

l 

REVERSED 

120 

l 

RESERVED 

l 122 

1 

RESERVED 

12tt 

H.GARD 1 

ADDRESS OF STACK GUARD WORD 

1 126 

H,NLUN i 

COUNT OF LOGICAL UNITS 

1 130 

H.LUN \ 

START OF LOGICAL UNITS 

l 132 

m m 

EACH LUN CONSISTS OF 

m 

l 

TWO WORDS, UP TO 255 

i 

m m 

l 

LUNS CAN BE ACCOMODATED 

m 

l 

m m 

/ 

m i mm 

t 

m 

/ 

/ 

• 

/ 

/ 

• 

/ 

l 

• m 


l 

m m 


l l 


' (2feV6 e&6p ' ?! 

(x \)<A- 

) 
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LAST LUN ENTRY 



l 1 

....—floating POINT or eae 

1 SAVE AREA l 

........ (3 OR 25 WORDS) 

/ / 

/ / 

/ / 


1 l 

1 

CURRENT PS 

l 

l 

CURRENT PC 

l 

l 

CURRENT R5 

l 

i 

CURRENT Ra 

l 

l 

CURRENT R3 

l 

l 

CURRENT R2 

l 

l 

CURRENT Rl 

1 

1 

CURRENT R0 

t 

l 

STACK GUARD WORD 

l 
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CHAPTER 3 


5.4 I/O DATA STRUCTURES 

Of all the control blocks In the I/O data structure* only four are of 
direct concern to a driven 

t. The I/O Packet f 

2. The DCBf 

3. The UCB* and 

4. The SCB, 

Although the data structures contain an abundance of data pertaining 
to Input/output ooeratlons* drivers per se are Involved only with a 
subset of this data. Most of the data which Is used by a driver is 
supplied In the data structure source* and Is not referenced during 
driver execution. 


5,4.1 The I/O Packet 

S' - i 

Figure 3-1 Is a layout of the 18-word I/O Packet which Is constructed 
and placed In the driver I/O queue by QIO directive processing and 
subseauently delivered to the driver by a cell to SGTPKT, Figure 3-2 
Is the OPB from which the I/O Packet Is generated, r; • 2 
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I. INK 
I.EFN 

I * PR I 

l LINK TO NEXT I/O PACKET 

m m mm 

1 


l EFN i PRI 

l 

a 

I.TC0 

l TCB ADDRESS OF REQUESTER 

l 

a 

I.LN2 

l ADDRESS OF SECOND LUT WORD 

l 

fe 

I.UCB 

l ADDRESS OF REDIRECT UCB 

l 

10 

I.FCN 

l FUNCTION CODE l MODIFIER 

l 

12 

I.IOSB 

IVIRTUAl ADDR OF I/O STATUS 

BLKl 

14 


l RELOCATION BIAS OF IOSB 

l 

16 


l REAL ADDRESS OF IOSB 

\ 

20 

I. AST 

1 VIRTUAL. ADDR OF AST SERVICE 

RTNJ 

22 

I.PRM 

l 

l 



1 

new T cw 

1 

l 

Wu v 111 

PARAMETERS 

t 

i 

t 

l 


l 

1 


l 

i 1 

1 l 


Figure 3»1 I/O Packet Format 

ly I 
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5,41,1,1 I/O Packet Details • The I/O Packet is built dynamically by 
QIO directive processing. Thus# no static fields exist with respect 
to a driver, I/O Packets are created dynamically and# therefore# the 
first parameter does not apply. Fields are classified ast 

not referenced# 
read-only# or 
read/wr i te. 


I.UNK 


Description! 

Links I/O Packets queued for a driver, A zero ends the 
chain. The listhead is in the SC8 (5.LHD), 

Initial ization/Access! 

not referenced, 

I , PR I 

Desc r i ot i on! 

Priority copied from the TCB of the reauesting task, 
Initializati on/ Access! 
not referenced, 

I , EFN 

Desc r i pt i on ! 

Contains the event flag number as copied by QIO directive 
processing from the requester's DPB, 

Initial izati on/ Access t 

not referenced, 

I. TCB 

Descri pt i oni 

TCB address of the requesting task. 

Initial izati on/Accessj 
not referenced. 



I.LN2 
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Descript 1 on* 

Contains the address of the second word of the LUT entry in 
the task header to which the I/O reouest was directed. For 
open files on file structured devices# this word contains the 
address of the window block# otherwise It Is zero, 

Inltlallzatlon/Access* 

not referenced. 


I • UCB 

Descript 1 on* 

Contains the address of the Redirect UCB If the starting UCB 
has been subject to a Redirect MCR command. 

Initial 1 zat Ion /Access* 

not referenced. 


I.FCN 


Descript Ion* 

Contains the function- code (see table 3*1) for the I/O 
request , 

Inltlallzatlon/Access* 
read*on 1 y , 


I, I0S8 

Description* 

XalOSB contains the virtual address of the I/O Status block 
(lOSB) If one Is specified or zero If not. 

I.IOSB+2 and I.I08B+4 contain the address doubleword for the 
IOSB (see Appendix A for a detailed description of the 
address doubleword). On an unmapped system# the first word 
Is zero# the second word Is the real address of the IOSB, 

In a mapped system# the first. word contains the relocation 
bias of the IOSB* the bias Is# in effect# the 32*word block 
number In which the IOSB starts. This block number Is 
derived by viewing available real memory as a collection of 
32*word blocks numbered consecutively# starting with 0, 
Thus, If the IOSB starts at Physical location 3210(8)# Its 
block number Is 32(8). 
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The second word is formatted as follows* 

Bits 0-5 Displacement In Block C D 1 8 5 
Bits 6-12 AH zeros 
Bits 13-15 6 

The displacement in block is the offset from the block base* 
In the above example where the IOSB started at 3210(6), the 
DIB is equal to 10(0), 

The value 6 in bits 13-15 is constant. It is used to cause 
an address reference through Kernel Page Address Register 6, 
Again, see Appendix A for details. 

The deferral of a discussion of the address doubleword to an 
appendix reflects the fact that a writer of a conventional 
driver has almost no need to concern himself with the 
contents or format of the address doubleword. Its 
construction and subsequent manipulation are normally 
external to the driver* subroutines are provided as Executive 
services for programmed I/O to render the manipulations of 
I/O transfers transparent to the driver itself. 

Initial ization/Accessj 

not referenced. 


I, AST 


Oesc r i pt i on i 

Contains the virtual address of the AST service routine to be 
executed at I/O completion. If no address is specified, the 
field contains zero* 

Initial ization/Accessi 

not referenced. 


X.PRM 

Descriot i om 

Device dependent parameters copied from the DPB, 
Initialization/Accessi 

not initialized, read-only. 
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The QIO Directive Parameter Block CDPB5 la constructed as 


m m 

l 

LENGTH 

mm m i 

i 

DIC 

«■ m m 

l 

0 

1 

FUNCT CODE 

i 

MODIFIER 

l 

2 

l 

RESERVED 

i 

LUN 

\ 

a 

l 

PRIORITY 

1 

EFN 

l 

6 

l 

I/O STATUS BLOCK ADDRESS 

i 

10 

1 

AST ADDRESS 

i 

12 

1 

DEVICE 

l 

14 

l 

DEPENDENT 

l 

16 

1 

parameters 

1 

20 

l 




1 

22 

l 




1 

24 

l 


» m m m 


l 

mmm 

26 


Figure 3*2 QIO DPB 



f o 1 1 o w a t 
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The parameters have the following 1 nteroretat 1 on. 

Length ( requ i red) i 

The length of DP8, whieh for the RSX^llM GtO directive, is always 
fixed at twelve words, 

DIG (required)* 

Directive Ident 1 f 1 cat i on Code, For the QIO directive, the value 
1 s a 1 , 

Function Code (required)* 

The code of the requested I/O function (0 thru 31,), 

Modi f 1 er * 

Device dependent modifier bits. 

Reserved* 

Reserved byte and must not be used, 

LUN (required)* 

Logical Unit Number, 

P r 1 o r 1 1 y * 

Request priority. Ignored by RSX-11M, but space must 
be allocated for RSX»11D compatibility, 

EFN (optional)* 

Event flag number, 

I/O Status Block Address (optional)* 

This word contains a pointer to the I/O status block which is a 
2*word device dependent I/O completion data packet formatted as* 

Byte 0 

I/O status byte. 

Byte 1 

Augmented data supplied by the driver 


Bytes 2 and 3 
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The contents of these bytes depend on the value of byte 0, 
If byte 0=1# then these bytes usually contain the 
processed byte count. If byte 0 does not equal zero# then 
the contents are device dependent, 

AST Address (optlonal)i 

Address of an AST Service Routine, 

Device Dependent Parametersi 

Up to six parameters specific to the device and I/O function to 
be performed. Typically for data transfer functions these arei 

Buffer address 


Byte count 

Carriage control type 
Logical block number 

Any optional parameters that are not specified should be filled with 

zeros. 
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5,4,2 Device Control Block 

The device control block (DCBD defines generic information about a 
device type and the lowest and highest unit numbers. There is at 
least one DCB for each device type in a system. For example, if there 
are teletypes in a system, then there is at least one DCB with the 
device name # TT', If part of the teletypes were interfaced via 
DLli-A's and the remainder via a DHll, then there would be two DCB's. 
One for all DLll-A interfaced teletypes and one for all DHll 
interfaced teletypes. 


d.lnk 

l LINK TO NEXT DCB CBaLAST) 

m 

1 

0 

D, UCB 

l LINK TO FIRST UCB 

l 

2 

D , NAM 

l GENERIC DEVICE NAME 

\ 

a 

D.UNIT 

l HIGHEST UNIT #IL0WEST UNIT A 

i 

6 

D.UCBL 

J LENGTH OF UCB 

l 

10 

0, DSP 

t AODR OF DRIVER DISPATCH TABLE 

1 

12 

V.MSK 

1 LEGAL FCN MSK BITS 0-15. 

l 

14 


1 CONTROL FCN MSK BITS 0-15, 

l 

16 


i NO-OP'ED FCN MSK BITS 0-15, 

l 

20 


i ACP FCN MSK BITS 0-15. 

l 

24 


1 LEGAL FCN MSK BITS 16.-32, 

l 

26 


l CONTROL FCN MSK BITS 16,-32. 

l 

30 


1 NO-OP # ED FCN MSK BITS 16.-32. 

1 

32 

' 

1 ACP FCN MSK BITS 16.-32. 

i 

3« 


Figure 3-3 Device Control Block 


5.U.2.1 

DCB Details 




D.tNK (Link to next DCB)* 


* Parent hesi led contents indicate value to be initialized in the data 
base source. 
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Desc rl Dt I on* 

Address link to the next DCB, A z ere In this field Indicates 
the last DCB In the chain. The driver writer links his DCB 
Into the system DCB's via the global label SUSRT8 on his 
first DCB. 

Initial Izatl on /Access? 

Initialised# not referenced, 

D.UCB (Pointer to First UCB) 

Descrl pt Ion? 

Address link to the first and possibly the only UCB 
associated with the DCB, All UCB's# for a given DCB# are In 
contiguous memory locations and must all be the same length. 

Initial liatlon/Access? 

Initialized# not referenced, 

D.NAM (ASCII Device Name) 

Descrl Dt I on? 

Generic device name In ASCII by which device units are 
mnemonlcally referenced. 

Initialized on/Accessi 

Initialized# not referenced, 

D.UNIT (Unit Number Range) 

Description? 

Unit number range for the device. This range covers those 
logical units available to the user for device assignment. 
Typically# the lowest number Is zero and the highest Is n»l# 
where n Is the number of devlce»unlts described by the DCB, 

Inltlallzatl on/ Access ? 

Initialized# not referenced, 

D.UCBl (UCB Length) 

Descrl pt I on? 

The UCB may have any length to meet the needs of the I/A? DCB 
must have the same length. 
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Initial iiation/ Access! 

initialised, not referenced, 

O.OSP (Dispatch Table Pointer) 

Desc r i pt i on j 

Address of the driver dispatch table, 

When the Executive wishes to enter the driver at any of the 
four entry points contained in the driver dispatch table, it 
accesses D,DSP, locates the appropriate address in the table, 
and calls the driver at that address. Thus, null addresses 
are not permitted. If the driver does not process a given 
function, then it simply returns. The driver writer must 
provide a driver dispatch table in the driver source. The 
label on this table is of the form SnnTBL and mu9t be a 
global label. The designation nn is the 2»character generic 
device name for the device. Thus, $TTTBL is the global label 
on the driver dispatch table for the generic device name TT, 
This table is an ordered 4»word table containing the 
following entry pointsi 

I/O Ini t i ator f 

Cancel I/Of 

Device Timeout, and 

Power failure, 

when a driver is entered at one of these entry points, entry 
conditions are as follows! 

At Initiator! 

If UC.QUEsl 

R5 « UCB address 

R1 s Address of the I/O Packet 

If UC , QUE«0 

R5 * UCB address 

Interrupts are allowed. 

At Cancel I/Oi 

R5 « UCB address 

R4 a SCB address 

R3 = Cent rol 1 er i ndex 

Rl a Address of TCB of current task 

R0 a Address of active I/O packet 
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Device interrupts are locked out. 

At Device Timeout* 

R5 * UCB address 
R4 a SCB address 
R3 a Control 1 er 1 ndex 

R0 ■ I/O status code IE.DNR (Device Not Ready) 

Device Interrupts are locked out. 

At Power Failure* 

R5 a UCB address 
R4 a SCB address 
R3 a Cont roller 1 ndex 

Interrupts are allowed. 

Ini 1 1 a 1 1 fat 1 on/Access i 

Initialised# not referenced, 

D.MSK (Function Masks) 

Descript 1 on* 

There are eight words beginning at D.MSK which are of crltl- 
ca) Importance to the proper functioning of a device driver. 
The Executive uses these words to validate and dispatch the 
I/O request specified by a QIQ directive. The description 
which follows applies only to non-file structured devices# as 
directions for writing drivers for file structured devices 
(drivers which Interface to FCP) are not Included In this 
manual. Four masks# 2»worda per mask# are described by the 
bit configurations established by the driver writer for these 
words, 

1, Legal function mask* 

2, Control function mask* 

3, No«op # ed function mask, and 

4, ACP function mask. 

The Q 10 directive allows for 32 possible I/O functions. The 
masks# as stated# are filters to determine validity and I/O 
requirements for the subject driver. 

The function value In the I/O request Is filtered by the 
Executive through the four mask words, I/O function codes 
range from 0»31 f If the function corresponds to a true 
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condition In a mask word, a bit Is set In the mask In the 
position which numerically corresponds to the function code. 
Thus# If the function 5 is legal# then bit 5 In the Leqal 
Function M ask Is set. 


The masks are laid out In memory in two u-word groups. Each 
4-word group covers 16 function codes. The first four words 
cover the function codes 0-15,# the second four words cover 
codes 16-31, Below Is the exact layout used for the driver 
example In Chapter 5, 


.WORD 

140033 

.WORD 

30 

.WORD 

140000 

.WORD 

0 

.WORD 

5 

.WORD 

0 

.WORD 

1 

.WORD 

4 


fUEGAL FUNCTION MASK CODES 0-15, 
^CONTROL FUNCTION MASK CODES 0-15, 

* NO-OP # ED FUNCTION MASK CODES 0-15, 

* ACP FUNCTION MASK CODES 0-15, 

I LEGAL FUNCTION mask CODES 16,-31. 
ICONTROL FUNCTION MASK CODES 16,-31, 
j NO-OP # ED FUNCTION MASK CODES 16,-31, 

* ACP FUNCTION MASK CODES 16,-31, 


The mask words filter sequentially as follows* 


Legal Function Mask* 

Legal function values have the cor respondl ng bit position in 
this word set to 1, Function codes that are not legal are 
rejected by QIO directive processing by returning IE,IFC In 
the I/O status block, provided an IQSB was specified. 

Control Function Mask* 

If any device dependent data exists in the DPB# and this data 
does not reoulre further checking by the QIO directive 
processor# the function is considered In the class <control 
function*. Such a function allows 010 directive processing 
to copy the DPB device-dependent data directly Into the I/O 
Packet , 

No-op'ed Function Mask* 

A no-op function Is any function that Is considered 
successful as soon as It Is Issued, If the function Is a 
no-op# QIO directive processing Immediately marks the reauest 
successful* no additional filtering occurs, 

ACP Function Mask* 


If a function code Is legal# but neither control nor no-oo# 
then It Is either an ACP function or a transfer function. If 
a function code may require Intervention of an Ancillary 
Control Processor (ACP)# the cor respondl ng bit In the ACP 
function mask must be set. 
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In the specific case of read/write virtual functions, the 
cor resoondi ng mask bits may be set at the driver writer's 
option. If the co r respond i ng mask bits for a read/write 
virtual function are set, QIO directive processing will 
recognize that a f i 1 e-o r i ent ed function is beimg reauested to 
a non-file structured device and convert the reauest to a 
read/write logical function. 

This conversion is particularly useful. Consider a 
read/write virtual function to a specific device: 

1, If the device is file structured and a file is open 
on the specified LUN, the block number specified is 
converted from a virtual block number in the file to 
a logical block number on the medium and the reauest 
is queued to the driver as read/write logical, 

2, If the device is file structured and no file is open 
on the lun, then an error is returned and no further 
action is taken, 

3, If the device is not file structured then the request 
is simply transformed to read/write logical and 
queued to the driver, (Specified block number is 
unchanged) , 

Transfer Function Processing 

Finally, if the function is not an ACP function, then by 
default, it is a transfer function. All transfer functions 
cause the QIO directive processor to check the specified 
buffer for legality (i.e,, is it within the address space of 
the reauesting task), and proper alignment (i*e«, word or 
byte). Also, the number of bytes being transfered is checked 
for proper modulus (i,e*, nonzero and a proper multiple). 

Initial i zat i on/ Access t 

initialized, not referenced. 


Mask Word Creation 

The creation of the function mask words involves three steps: 

1, Establish the I/O functions available on the device for which 
driver support is to be provided, 

2, Check the standard R3X-11M function code values in table 3-1 
for equivalencies. Only function code 0 is mandatory. 
Function codes 3 and <1, if used, must have the RSX-11 M system 
i nterpret at i on. It is suggested that functions having an 
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RSX-liM system counterpart uae the RSX-llM code# but this Is 
not required except in the case where the device is to be 
used in conjunction with an ACP, From the supported function 
list, the two legal function mask words can be built, 

3, Given the legal function mask# 

3a, The Control Function mask is built by asking* 

Does this function carry a standard buffer address and 
byte count in the first two device dependent parameter 
words? 

If it does not# then it either qualifies as a control 
function# or the driver itself must effect the checking and 
conversion of any addresses to the format required by the 
driver, (Buffer addresses in standard format are 
automatically converted to Address Doubleword format,) 

Control functions are, essentially, those whose DPB's do not 
contain buffer addresses or counts, 

3b* The No-op Function Mask is created by deciding which legal 
functions are to be no-oo'ed, Typically# for File Control 
Services (FCS) compatibility on non-file structured devices# 
the file access/deaccess functions are selected as legal 
functions even though no specific action is required to 
access or deaccess a non-file structured device* thus# the 
access/deaccess functions are no-op'ed, 

3c, Finally# the AC? functions Write Virtual Block and Read 
Virtual Block may be included. Other ACP functions that 
might be included fall into the non-convent i one 1 driver 
classification and are beyond the scope of this document. 


; A / 

3, 1 , 2, 2 I/O Function Codes • The filtering process which cascades 
through the function mask words in the DCB uses the function code byte 
supplied in the QIO directive DPB as the match value. Table 3-1 
contains the function values used for DEC-suoplied drivers. 
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TABLE 3-1 

STANDARD I/O FUNCTION CODES 


FUNCTION 
VALUE (8) 


EQUATED 

SYMBOLIC 


I/O 

FUNCTION 


0 

1 

2 

3 

4 

5 

6 
7 

10 

11 

12 

13 

14 

15 

16 
17 
20 
21 
22 

23 

24 

25 

26 
27 

30 

31 

32 

33 

34 

35 

36 

37 


IO t K IL 
IO.WLB 
IO.RLB 
10, ATT 
10, DET 


10, FNA 

IO.RNA 
10, ENA 
10, ACR 
10 , AC W 
10, ACE 
IO.DAC 
10, RVB 
IO.WVB 
10, EXT 
IO.CRE 
10, DEL 
10, RAT 
10, WAT 


CANCEL I/O 

WRITE LOGICAL BLOCK 

RE AO LOGICAL BLOCK 

ATTACH DEVICE 

DETACH DEVICE 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

FIND FILE IN DIRECTORY 
UNUSED 

REMOVE FILE FROM DIRECTORY 

ENTER FILE IN DIRECTORY 

ACCESS FILE FOR READ 

ACCESS FILE FOR READ/WRITE 

ACCESS FILE FOR PEAD/WR ITE/EXTEND 

DEACCESS FILE 

READ VIRTUAL BLOCK 

WRITE VIRTUAL BLOCK 

EXTEND FILE 

CREATE FILE 

MARK FILE FOR DELETE 

READ FILE ATTRIBUTES 

WRITE FILE ATTRIBUTE'S 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 


Of the function code values listed In Table 3«i # only IO.KIL la 
nandatory and has a fixed Interpretation, However# If 10, ATT and 
10, DET are used, they nust have the standard meaning. If QIO 
directive processing encounters a function code o* 3 or 4 and the code 
Is not no-op*ed# It will assurce they represent Attach device and 
Detach device# respectively, The other codes are suggested but not 
nandatorv» The driver writer Is free to establish all other function 
code values on non-file structured devices. The mask words must 
obviously reflect the proper filtering process. 
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If a driver is being written for a file structured device, 
standard function codes of Table 3-1 must be used. 


the 
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5,4,3 Status Control Block 

The status control block (SCB) defines the status of a device 
controller. There la one SCB for each controller Is a system. The 
SCB Is pointed to by unit control blocks. To expand on the teletype 
example above, each teletype Interfaced via a 0 L 1 1 * A would have a SCB 
since each DLll*A Is an Independent Interface unit. The teletypes 
Interfaced via the DHll would also have an SCB since the DHil Is a 
single controller but multiplexes many units In parallel. 


S.LHD l DEVICE I/O QUEUE l 0 


i LISTHEAD \ 2 

S I VCT JVECTOR ADDR/4 1 DEVICE PRIORITY l 4 

S,CTM 

S.ITM UNIT TMEOUT CNTJCURNT TMOUT CNT J 6 


S, CUN 

S , STS 

m « 

l 

CTRLR STATUS ICONTROLLER 6*2 

i m 

l 

10 

S.CSR 

1 

ADDRESS OF CONTROL STATUS REG 

\ 

12 

S,PKT 

t ADDRESS OF CURRENT I/O PACKET 

i 

14 

S , FRK 

i 

FORK LINK WORD 

i 

16 


1 

FORK PC 

i 

20 


1 

FORK R5 

l 

22 


l 

FORK R4 

l 

24 


Figure 3«»4 Status Control Block 

p, - a- 


5,4,3, 1 SCB Details 

S,LHD (first word eauals zero! second word points to first) 
Description! 

Two words which form the I/O queue llsthead. The first word 
polnta to the first I/O Packet in the aueue end the second 
word points to the last I/O Packet in the queue. If the 
aueue Is empty, the first word is zero and the second word 
points to the first word. 
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Initial izati on /Access! 

initialized* not referenced, 

S.PRI (device priority) 

Desc r 1 pt 1 on i 

Contains the priority at which the device interrupts. 

Initial ization/Accesa! 

initialized# not referenced, 

S.VCT (Interrupt vector divided by four) 

Description! 

Interrupt vector address divided by four. 

Initial ization/Accesai 

initialized# not referenced, 

S,CTM (initialize to zero) 

Descri pt 1 oni 

RSX-UM supports device timeout# which enables a driver to 
limit the time that elapses between the Issuing of an I/O 
operation and its termination. The current timeout count (in 
seconds) is initialized by moving S,ITM (initial timeout 
count) into S.CTM, The Executive clock service will examine 
active times# decrement them and# if they reach 0# call the 
driver at its device timeout entry point. 

The internal clock count is kept in l-second Increments, 
Thus# a time count of 1 is not precise# since the internal 
clocking mechanism is operating asynchronously with driver 
execution. The only meaningful minimum clock Interval is 2 
if the programmer intends to treat timeout as a consistently 
detectable error condition. Note# if the count is 0# that no 
timeout will occur* it is# in fact# an indication that 
timeout is not operative. The maximum count is 255, The 
driver writer is responsible for setting this field. 
Resetting is at actual timeout or within SFORK, 

Initialization/Access! 

not initialized# read/write, 

8, ITM (set to initial timeout count) 



page 9a 


Descriot 1 on t 

Contains the initial timeout value, 

Initialization/Accesst 

initialized# read-only, 

S , CON (controller number times 2) 

Desc r i ot i on i 

Controller number multiplied bv 2, Used by drivers which are 
written to support more than one controller, S,C0N nay be 
used by the driver to index into a controller table created 
and maintained internal to the driver itself. Indexing the 
controller table enables the driver to service the correct 
controller when a device interrupts. 

Initial iiation/Aceessi 

initialized# read-only, 

S,STS (initialize to zero) 

Descriot iom 

Establishes the controller as busy/not busy. This byte is 
the interlock mechanism for marking a driver as busy for a 
specific controller, Tested and set bv SGTPKT and reset by 
SIODON, 

Ini t i al i zat ion/Ac cess I 

initialized# not referenced, 

S,CSR (Control Status Register address) 

Descript i oni 

Contains the address of the Control Status Register (CSR) for 
the device controller, S,CSR is used by the driver to 
initiate I/O operations and to access# via indexing# other 
registers related to the device that are located in the I/O 
page. This address need not be a CSRi it need only be a 
member of the device's register set. It is accessed at 
system bootstrap time to determine if the interface exists on 
the system hosting the Executive, The Executive uses this to 
set the off-Hne bit at bootstrap so system software can be 
interchanged between systems without an intervening system 
generation. Otherwise# it is only accessed by the driver 
itself, 
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Inltlallzatlon/Accessi 

initialized# read/only, 

S , PKT (Reserve on© word of storage) 

Oeserl pt 1 on* 

Address of the current I/O Packet established by SGTPKT, 
This field Is used to retrieve the I/O Pocket address upon 
the completion of an I/O reauest, 

Inltlalliatlon/Accessi 

not Initialized# read-only, 

S,FRK (reserve four words of storage) 

Desc r 1 pt 1 on * 

The four words starting at S.FRK are used for fork block 
storage if and when the driver deems It necessary to 
establish Itself as a Fork process. Fork block storage 
preserves the state of the driver which Is restored when the 
driver regains control at fork level. This area Is 
automatically used If the driver calls $F0RK, 

Inltlallzatl on/Accessi 

not ■ Ini tl all zed# not referenced. 



PAGE 96 


5,4,4 Unit Control Block 

The unit control block (UC8) defines the status of an individual 
device unit and is the control block that is pointed to by the first 
word of an assigned LUN, There is one UCB for each device unit of 
each DCB, The UCB's associated with a particular DCB are contingous 
in memory and are pointed to by the DCB, UCB's are variable length 
between deb's but are of the same length for a specific DCB, To 
finish the teletype example above, each unit on both interfaces would 
have a UCB, 


m 

U , DCB i 

BACK POINTER TO DCB 

m 

l 0 

U, RED l 

ij r t i • 

REDIRECT POINTER TO UCB 

1 2 

U , STS 

U ST ? 

CONTROL FLAGS l UNIT STATUS 

i 4 

U.UNIT 

STATUS EXT iPHYSICAL UNIT * 

1 6 

U.CWl 

CHARACTERISTICS WORD #1 

1 10 

U.CW2 

CHARACTERISTICS WORD #2 

1 12 

U,CW3 

CHARACTERISTICS WORD #3 

l 14 

U.CW4 

CHARACTERISTICS WORD *# 

1 16 

U.SCB 

POINTER TO SCB 

1 20 

U , ATT 

TCB OF ATTACHED TASK 

i 22 

U.BUF 

BUFFER RELOCATION BIAS 

1 24 


BUFFER ADDRESS 

1 26 

U.CNT 

BYTE COUNT 

i 30 


DEVICE 

1 


DEPENDENT 

1 

• 

• 

• 

ai 

STORAGE 

1 

m m 
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9,4,4, 1 UCB Detai 1 s 
U,DCB (pointer to associated DCB) 

Desc r 1 pt 1 on * 

Backpointer to the cor respondi ng DCB* Since t 
block in the I/O data structure, access 
usually occurs via links Implanted in the UCB, 

Initial ization/Accessi 

initialised# not referenced, 

U,RED (initialized to point to U,0CB of the UCB) 

Desc ri pt 1 on i 

Contains a pointer to the UCB to which this device unit has been 
redirected, this field is updated as the result of an MCR Redirect 
command. The redirect chain ends when this word Points to the UCB 
itself. 

Initial Ization/Accessi 
Initialized# not referenced, 

U,CTl (set by driver writer) 

Description! 

U,CTL and the function mask words In the DCB drive 010 directive 
processing. The driver writer is totally responsible for setting up 
this bi,t pattern. Any Inaccuracy in the bit setting of U.CTU will 
produce erroneous I/O processing. Bit symbols and their meaning are 
as foil ows i 

UC.ALG • Alignment bit. 

If this bit b 0# then byte alignment of data buffers is 
allowed. If UC.ALG a 1# then buffers must be word 
al 1 gned, 

UC • ATT • Attach/Detach notification. 

If this bit is set# then the driver will be called when 
an Attach/Detach I/O function is processed by *GTPKT, 
Typically# the driver has no need to obtain control for 
Attach/Detach requests and the Executive performs the 
entire function without any assistance from the driver, 

UC,KIL - Uncondi t 1 onal Cancel I/O call bit. 


9 UCB is a key control 
to other control blocks 


r mA 4^ 

'9ec|iiv\. uof^ 

7 ^ bledc 

fvVvu^ 
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If set# the driver Is to be called on a Cancel I/O 
request even if the unit specified is not busy. 

Typically# the driver is called on Cancel I/O only if an 

I/O operation is in progress, 

UC.QUE » Queue bypass bit. 

If set, the QIQ directive processor is to call the driver 
prior to queueing the I/O Packet, Once gaining 
to-be«queued control# t he di spos i t i on of the I/O Packet 
is the driver's responsibility. Typically# an I/O Packet 
is queued prior to a call to the driver# which later 
retrieves it by a call to SGTPKT , 

UC.PWF • Unconditional call on power failure bit. 

If set# the driver is always to be called when power is 
restored after a power failure occurs. Typically# the 

driver is called on power restoration only when an I/O 

operation is in progress, 

UC,NPR » NPR device bit. 

If set# the device is an NPR device. This bit determines 
the format of the two word address in U,BUF (details 
given under the discussion of U.BUF), 

UCtLGH • Buffer size weak bits (2»bits), 

These two bits are used to check if the byte count 
specified in an I/O request is a legal buffer modulus, 

00 • any buffer modulus valid 

0t • must have word alignment modulus 

11 - must have double word alignment modulus 

10 - combination invalid, 

UC.ALG and UC,IGH are independent settings, 

UC.ATT# UC.KIL# UC,QUE# and UC.PWF will usually be zero# 
especially for conventional drivers. 

Every driver nust# however# be concerned with its particular 
values for UC.AlG# UC,NPR, and UC.LGH, 

The driver writer is totally responsible for the values in 
these bits# and erroneous values are likely to produce 
unpredictable results. 

Ini t i al i tat i on/Accessi 

initialized# not referenced. 
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U,STS (Initialise to zero) 

Desc r 1 ot 1 on j 

This byte contains device-independent status Information, 
The bit meanings are as follows! 

US,BSY - If set# device-unit is busy, 

US , MNlT - If set# volume Is not MQUnted, 

US,F0R - If set# volume Is foreign 

US, MOM • If set# device Is marked for dismount. 

The unused bits In U.STS are reserved for system use and 
expansion, US, MOM, US,MNT# and US, FOR apply only to 
MOUntable devices. 

Initial Izatlon/Accesst 

Initialized# not referenced, 

U,UNIT (unit number) 

Oescrl pt 1 oni 

This byte contains the physical unit number of the 
device-unit. If the controller for the device supports only 
a single unit# the unit number Is always zero, 

Inltlallzatlon/Accessi 

Initialized# read-only, 

U,ST2 (Initialize to zero) 

Description! 

This byte contains additional dev 1 ce- 1 ndeoendent status 
Information, The bit meanings are as follows! 

US.OFL - If set# the device Is offline (that Is# not In 
the conf 1 gurat 1 on) , 

The remaining bits are reserved for system use and expansion, 
Initialization/Access! 

Initialized# not referenced. 
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U.CWl (set by driver writer) 

Desc r i pt i on * 

The first of a 4-word contiguous cluster of device 
character i st i cs information, U.CWl and U,C^4 are device 
independent, U.CW2 and U,CW3 are device dependent. The four 
characteri st i c words are retrieved from the UCB and placed in 
the requester's buffer on issuance of a GIUN* Executive 
directive (Get LUN Inf ormat i on) , It is the responsibility of 
the driver writer to supply the contents of these four words 
in the assembly source of the driver data structure, 

U.CWl is defined as followsi 


DV , REC 
DV.CCL 
OV.TTY 
DV.OIR 
DV.SDI 
OV.SQD 
DV.PSE 
OV.COM 

DV , F 1 1 

0V • MNT 


Bit 0--Reco rd-0 r i ent ed De v i ce ( 1 * yes ) 
Bit l-«Carriage Control Devi ce ( laves) 
Bit 2--Terminal Dev i ce ( 1 syes ) 

Bit 3--Direetory Dev i ce ( 1 syes) 

Bit ^--Single Directory Dev i ce ( loyes) 
Bit 5--Sequent i a 1 DeviceC Isyes) 

Bit 12--Pseudo DeviceC Isyes) 

Bit 13--Deviee Mountable as a 

Communications Channel ( l«ves) 
Bit 14--Deviee mountable as a FILES-11 
devi ce( l«Ves) 

Bit 15--Device mountab 1 e ( 1 syes) 


Initial ixation/Accessi 


initialised, not referenced. 


U.CW2 (initialise to xerp) 


Deseri Pt i on* 

Specific to a given device driver (available for working 

storage or constants), 

Initialixati pn/Accesaj 

initialixed, read/write, 

U,CW3 (initialixe to xero) 

Desc r i ot i on i 

Specific to a given device driver (available for working 

storage or constants). 


Initialixati on/Accessi 
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initialised# read/write, 

lcu)4 

4 (set by driver writer) 

Description! 

Default buffer size. 

Initial liatl on /Access* 

initialised# read-only, 

B ( 9CB pointer) 

Description* 

THIs field contains a pointer to the SCB for tHIs UC9, In 
general# RU on entry to the driver via the driver dispatch 
table will contain the value In this word# since the SCB Is 
frequently referenced by service routines. 

Initial Isatl on /Access* 

Initialised# read-only, 

TT (Initialise to sero) 

Description* 

If a task has attached Itself to a device-unit# this field 
contains its TCB address. 

Initial Isatl on/Access* 

Initialised# not referenced 

U F (reserve two words of storage) 

Descrl pt 1 on* 

U, BUF labels two consecutive words which serve as a 
communication region between SGTPKT and the driver. If a non 
transfer function Is Indicated# then U,BUF# U.BUF+a, and 
U,CNT receive the first three parameter words from the I/O 
Packet • 

For transfer operations# the format of these two words 
depends on the setting of UC,NPR In U,CTl, The driver does 
not format the words* all formatting Is completed prior to 
the driver receiving control. For unmapped systems# the 
first word Is zero and the second word Is the physical 
address of the buffer. For mapped systems# the format Is 
determined by the UC,NPR bit which is set for an NPP device 



io 2, 


TktS pOjQC %Q,(LN& +C? be 
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L\CNT (reserve one word of storage) 

Desc r i pH on l 

Contains the byte count of the buffer described by U,BUF, 
The driver will use this field In constructing the actual 
device request. 

U.BUF and U.CNT are used to keep track of the current data 
Item in the buffer for the current transfer (except for NPR 
transfers). Since this field Is being altered dynamically, 
the I/O packet may be needed to reissue an I/O operation, 

Inltlalliatlon/Accessi 

not Initialized# read/write. 

Device Dependent hordsi 

Descrlot 1 oni 

The field Is variable In length and is established by the 
driver writer to suit dr 1 ver»spec 1 f 1 c reoul rements. 

Initialization /Accesst 

not Initialized# read/write. 



